construction:end_date -> opening_date

Proponowałbym pozamieniać construction:end_date na opening_date

Jedno występuje w Polsce, drugie generalnie.

Dodatkowo zainteresowani jesteśmy terminem otwarcia drogi a nie zakończenia budowy więc to standardowa nazwa jest w dodatku lepsza.

Czy są jakieś powody by takiej zmiany nie zrobić na obiektach highway=construction? (i building=construction jeśli jest to tam użyte)

https://taginfo.openstreetmap.org/keys/construction%3Aend_date#map

https://wiki.openstreetmap.org/wiki/Key:opening_date

construction:end_date to świetna nazwa dla tagu oznaczającego datę (planowaną) zakończenia budowy.

Natomiast z opening_date są same problemy.
Na wiki jest on opisany jako … data zakończenia budowy. Jest tam wiec utożsamione zakończenie budowy z otwarciem. To nie musi być prawda i na pewno nie jest to w przypadku dróg. Między zakończeniem budowy i otwarciem drogi zawsze mija trochę czasu, a bywają sytuacje, gdy wybudowanej drodze brakuje połączenia i jest ona przez dlugi czas zamknięta.

Tak nazwany i opisany tag wprowadza w błąd ludzi nieczytających wiki, a więc większość mapujących.

No właśnie. Nie jest to data otwarcia, tylko zakończenia budowy :slight_smile:

Też uważam, że te dwa tagi wcale nie muszą być współzamienne. Czasem na budowlanych tablicach informacyjnych podawane są jawnie właśnie daty początku i (przewidywanego) zakończenia budowy, podczas gdy data otwarcia jest nieznana. A czasem jest wręcz przeciwnie - inwestor chwali się w mediach tylko datą otwarcia. Więc IMHO to nie są tożsame klucze i ich rozróżnienie wydaje się wprowadzać większą precyzję - przynajmniej w założeniu. Jak to wygląda w praktyce i czy nie jest używane zamiennie, to już inna sprawa.

Niezależnie od tego nie jestem przekonany czy przetagowanie tego jest warte zachodu, bo to są zwykle tymczasowe informacje, które i tak prędzej czy później w najlepszym przypadku zostaną zamienione na start_date.

Dodałem trochę na wiki, ale co do opening_date znaczenie (data otwarcia, po ukończeniu całego procesu) jest dość jednoznaczna.

Motywowany jestem głównie tym że StreetComplete tego używa (by nie pytać się o to czy droga jest otwarta tam gdzie budowa jeszcze lata będzie trwać).

Patrz np. https://www.openstreetmap.org/way/721168849/history gdzie SC się bez sensu pytało

W praktyce to mamy zbędny dubel. I tak jest to przewidywanie, dzielenie tego na osobne klucze o rzekomo różnym znaczeniu to utrudnienie sobie i innym życia. Teraz w dodatku do popularnego opening_date trzeba będzie jeszcze drugie obsługować

Lepiej byłoby do opening_date dać datę zakończenia budowy (planowaną) a najwyżej potem wydłużyć jak coś będzie wiadomo

A bywa, że i standardowe start_date/end_date jest używane zamiennie…
https://www.openstreetmap.org/way/304973954/history

… co w sumie jest jeszcze większym wyzwaniem, bo nie da się tego przetagować z automatu.

Teraz jest znacznie lepiej, jako data otwarcia, ale został jeszcze stary tekst w description.

Na pewno nie jest to dubel, skoro są sytuacje, gdy te daty są różne. Ja bym nie proponował rozwiązania ogólnego w miejsce szczegółowego, bo to nie jest kierunek, w którym idzie OSM.

A osobiście mam obiekcje przed wpisywaniem podanej oficjalnie daty zakończenie budowy drogi do opening_date, bo to nie jest data otwarcia - jest to błąd rzeczowy.

Construction:end_date występować powinien z tagiem highway=construction dla dróg w budowie. Po zakończeniu budowy i oddaniu drogi do ruchu highway zmieniany jest na konkretny typ drogi a construction:end_date usuwany, jako zbyteczne oznaczenie remontowe. Może być wtedy zmieniany na opening_date. Rozróżnienie oznaczenia daty dla drogi w budowie (construction:end_date) od drogi już zbudowanej (opening_date) dla mnie jest bardzo przydatne w trakcie przeglądu i aktualizacji remontów. Nie będę się jednak upierać, jeżeli zdecydujecie inaczej. Poradzę sobie :slight_smile:
Jedno, co jest bardzo ważne - konsekwencja. Jeżeli już coś będzie oficjalnie ustalone to niech to będzie zapisane i stosowane. Nie ma nic gorszego niż używanie kilku metod oznaczania zamiennie.

No, baa. Tak Ci dobrze idzie, że powinieneś korzystać z tagu: construction:start_date
W końcu byłoby wiadomo czy zaczęto budowę DROGI
/mspanc/

Zobacz https://wiki.openstreetmap.org/wiki/Key:opening_date - to jest przewidywany termin otwarcia dróg w budowie

Stosowane na całym świecie, construction:end_date w zasadzie tylko w Polsce i nie ma dokumentacji

Jeśli już, to powinno być: construction:proposed_end_date

Śmiało zmieniaj Mateusz.
Tag construction:end_date jest syntaktycznie niepoprawny.

Dokładnie.

Oczywiście data zakończenia budowy nie musi się równać dacie otwarcia obiektu, może być też etap pośredni - kiedy prac budowlanych już nie ma, ale droga jeszcze nie jest otwarta. Ale takie szczegóły to raczej sprawdzi lokals, który często przejeżdża obok i może mapować te kolejne etapy. W przypadku zdalnego otwierania drogi interesuje nas czy droga jest przejezdna (czyli otwarta), a nie czy jej budowa się zakończyła.
W przypadku budynku może być nawet odwrotnie - tzn. budowa dokoła jeszcze jest, a budynek jest gotowy. W przypadku POI, data zakończenia budowy (czyli zdjęcia construction:*) będzie równała się dacie otwarcia sklepu lub podobnego POI, bo jeśli nie jest jeszcze otwarta, to nadal jest jako construction.

Tag opening_date to data zakończenia budowy, nie otwarcia obiektu. Interesuje nas kiedy zdjąć construction. Tak jak pisałem wyżej, zależy to od obiektu. Czasami czas między zakończeniem budowy a otwarciem obiektu jest bardzo krótki, np. w przypadku budowy Biedronek, Lidlów czy Aldików. A czasami długi: tu przykład https://www.openstreetmap.org/way/895745926, że parking jest już dawno wybudowany, ale minęły 3 miesiące i nadal nie jest otwarty z jakiegoś powodu, ale budowy już nie ma.

Dlaczego?

construction: to przedrostek dodawany do tagów obiektów, które są w budowie, zwykle dodawany do tagu głównego
end_date to data usunięcia obiektu, rzadko stosowany i raczej z historycznymi obiektami, które teraz pełnią inną funkcję

Czy w takim razie po zakończeniu budowy i otwarciu drogi do ruchu tag opening_date powinien zostać usunięty czy też zostawia się go w celach informacyjnych, historycznych etc? Bo niestety nagminnie znajduję ten tag z przeszłą datą, o pozostawianiu construction:end_date na otwartej drodze to już nie wspomnę :frowning:

To nie jest niepoprawność syntaktyczna. Construction to też klucz.

…end_date, …start_date czy …opening_date są raczej tagami tymczasowo informacyjnymi. Mające znaczenie bardziej dla mapujących niż dla ogółu.
Po zakończeniu budowy są, wcześniej, czy później, usuwane. Chyba, że, jak wspomniano wcześniej, są wartościami historycznymi.
Podobnie jest z nazwami budowy czy budowanych obiektów. Są one nadawane przez dewelopera w celach reklamowych, nie mające później żadnego znaczenia. Podobnie jak, dla przykładu, “Dom Waldka”. Chyba, że są wypisane na obiekcie.

tak

W obu przypadkach wskazane jest usuwanie

Tak, powinien zostać usunięty. To tylko informacja dla mapujących, żeby sprawdzić czy budowa już się zakończyła i trzeba coś dodać lub pozmieniać: czy to budynek, drogę lub coś innego. I powinna to być przyszła data, ta zapowiadana data zakończenia budowy. Oczywiście często zdarzają się opóźnienia, to wtedy można albo przedłużyć opening_date, albo dodać check_date, kiedy sprawdziliśmy, że budowa jeszcze jest.
Jeśli ktoś nie usunął opening_date po przetagowaniu na działający obiekt, to błąd. Na Wiki jest zapytanie overpass, które znajduje takie przeterminowane opening_date.

Dodając opening_date, można potem na Osmose znaleźć zakończone budowy.

Nieprawda, start_date nie ma nic do tego, można go dodać do każdego obiektu i jest to informacja dla użytkownika mapy, nie edytora.

Czyli co daje użytkownikowi? O tym czy dany obiekt się rozpoczął kilka lat temu a obecnie jest już dawno w użyciu, to wie dużo więcej z mediów. Zasada główna to to mapujemy ze stanem faktycznym a nie historycznym.
Na przykład o tym kiedy rozpoczęto budowę Pałacu Kultury w Warszawie, to przeciętny użytkownik nie potrzebuje start_date z OSM tylko ma Googla :slight_smile:

start_date ma też inny problem - to niweryfikowalne dane historyczne których w OSM być nie powinno