piebro/osm-data huggingface dataset:
Richard (2020-07-18 15:23:00+00:00): A wholesale revert would be an over-reaction.

OSM is iterative - it doesn't have to be 100% accurate at the first attempt, though it should take care never to be actively misleading. Lots of OSM data, particularly in remote or less travelled areas, has been added by reference to imagery. That includes surface quality information - for example, in areas of the rural US without significant tree cover, it's very often possible to discern approximate surface quality from imagery, and doing so is a great improvement on the base TIGER import.

So what Modest7 has done here is certainly not against standard mapping practice in OSM.

Rather, I think the main question is whether data consumers are likely to infer greater certainty from the tracktype= tag than armchairing can provide. There is obviously a difference between "I have surveyed this and it's definitely grade5" vs "I have looked at this from imagery and it seems grade5-ish". (That said, parsing tracktype= is very problematic anyway because international practice varies so greatly: in particular, the values are used differently in France, Germany, and the US, and I have different rules for each in cycle.travel.)

So my suggestion would be that any bulk edit should not be to revert this useful work, but to add "source:tracktype=imagery"; and that Modest7 should add that tag for future edits. (To the affected way, not the changeset; no-one parses way metadata with reference to changeset tags and nor should they be expected to.)

Richard (writing with my cycle.travel hat on)
Richard (2020-07-18 15:32:13+00:00): To add with reference to this particular example:

There is very very clearly a difference between https://www.openstreetmap.org/way/129297661 (which already had tracktype=grade2) and https://www.openstreetmap.org/way/370062638 (to which Modest7 has edited tracktype=grade4 in this changeset). If you can't see that from imagery I would strongly recommend you consult your local optician and/or computer monitor servicing technician.

This edit reflects that difference. So it has materially improved the OSM database in this area. Whether tracktype= is the ideal tag is another question (and that is more a failing of an imperfectly conceived, rather subjective tag tbh), but this edit adds useful information so should not be reverted.
rab (2020-07-18 15:42:51+00:00): Mit Kanonen auf Spatzen schiessen? Given the fact that the track type of nearby roads was added 10 years ago, we might also have a problem with pretending a high accuracy.
But all in all, comparing roads with given track type with nearby roads in the same area, on the same image. Then the results of couch mapping could be well in the range of local knowledge additions.
SomeoneElse (2020-07-18 19:28:30+00:00): Thanks Richard - a "source:tracktype=imagery" tag here would allow consumers (such as me!) to filter or flag stuff that may be dubious (I already do that for some other source tags).
Best Regards,
Andy
Nakaner (2020-07-18 19:32:18+00:00): Hi Modest7,

I forgot to mention this morning that I raised this topic on the Talk mailing list myself. That's why a couple of people commented to this changeset. https://lists.openstreetmap.org/pipermail/talk/2020-July/085082.html

Best regards

Michael
RobJN (2020-07-18 19:53:56+00:00): +1 to Richard's comments. Particularly that OSM is iterative and the suggestion to add "source:tracktype=imagery" rather than revert.
Leo Slager (2020-06-27 22:23:24+00:00): bicycle=yes is not a tag on a trafficlight.
Please stop with this kind of nonsense in the Netherlands.
Leo Slager (2020-06-27 22:28:33+00:00): reverted with my changset 87237388
BCNorwich (2020-06-28 06:34:03+00:00): Hi Welcome to OpenStreetMap.

This path is a cycleway as designated by the council. It's part of Enfield Chase to Arnos Park Greenway, one of the older cycleways to be made. The route is also mapped in OSM  here :-https://tinyurl.com/y74w7rvk 
I've reinstated the cycleway tags.

Regards Bernard.
satoshich1988 (2020-06-28 07:43:50+00:00): Hi Bernard,

That makes sense, thank you. I was trying to add the fact that pedestrians are allowed. It didn't have the foot=designated tag before and it said segregated=mo instead of segregated=no. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway says that for a path like this "highway=cycleway + foot=designated + segregated=no" or "highway=path + bicycle=designated + foot=designated + segregated=no" are both valid options. I went for the second option but I am ok with the first.

Thanks!
rene78 (2021-03-21 12:34:15+00:00): Hey Angys,

the tag shop=variety_store is for 1RM shops, where you can buy all types of crap and is not the right tag for 99 Speedmart in my opinion. shop=convenience is much more suitable in my opinion.

Rene
angys (2021-03-21 13:52:07+00:00): Hey plz check out previous discussion on GitHub
rene78 (2021-03-21 14:05:28+00:00): Recommendation is "convenience" (https://github.com/osmlab/name-suggestion-index/blob/93395501f9373dced7a41a6be656719c0cf922e6/brands/shop/convenience.json#L48)
rene78 (2021-03-21 14:06:30+00:00): Those are the presets, which are also used in iD editor by the way.
angys (2021-03-21 14:08:55+00:00): https://github.com/osmlab/name-suggestion-index/issues/4816
george1201 (2025-12-09 22:40:52+00:00): Hallo Radboss,
ich habe eine Anmerkung (bzw. Gedanken) zu den eingetragenen Flächen landuse=basin, also w820274615 bis w820274620. Die Versickerungsmöglichkeit von Regenwasser ist sicher einer der Aufgaben dieser Flächen. Aber man beginnt jetzt auf einigen der Grasflächen Spielgeräte zu installieren (wahrscheinlich nicht bei allen).
Ein unwissender Spaziergänger, der hier vorbeikommt, wird deshalb zuallererst einen Spielplatz sehen. Wenn ich ihm dann sage, dass es ein Regenwasserversickerungsbecken ist, wird er wahrscheinlich auch nicht widersprechen. Es ist eben beides.
Ich frage mich: Wie kann man dies passend mappen?
Radboss (2025-12-12 00:17:51+00:00): Hallo George1201, wenn beides klar ersichtlich ist und sich Versickerungsbecken und Spielplatz überschneiden, spricht etwas dagegen dies dann auch direkt so als zwei überlappende Flächen einzutragen: landuse=basin und ein separates leisure=playground? In Hohenwettersbach gibt es übrigens ein ähnliches Szenario: https://osm.org/go/0DlEL~Yxt?m= bzw. geo:48.965778,8.480183?z=19
george1201 (2025-12-12 23:00:08+00:00): Stimmt. Einen solchen Fall gibt es sogar bei mir in der Nähe: Im Schmallen von Oberreut. Einen leisure=playground muss man über jeden landuse legen dürfen. Bevor ich Spielplätze hier im August-Klingler-Areal eintrage, warte ich aber noch etwas ab. An den Grünflächen wird zur Zeit ja noch gearbeitet.
george1201 (2026-01-06 00:05:13+00:00): Jetzt gibt es auch den Hinweis https://www.openstreetmap.org/note/5116378 dazu.
verpfeilt (2026-01-08 02:32:00+00:00): Mir ist es in StreetComplete und OSMand (ansonsten bin ich OSM noob und mappe vor allem Spielgeräte auf Spielplätzen) negativ aufgefallen, weil es dort optisch nach Wasserbecken aussieht. Als wären hier sehr viele Teiche. Obwohl OSM Apps die Gegend schon genauer abbilden als Google Maps, sieht es halt immer noch nicht korrekt aus. Was, wenn etwas nur Grünfläche und kein Spielplatz wird? Können wir dennoch Informationen liefern, die ein besseres rendering ermöglichen? Sowas wie "(niedrige) Begrünung"?
verpfeilt (2026-01-08 02:55:58+00:00): Nachdem ich mir nochmal die Doku zu Basin angeschaut habe, bin ich mir auch nicht sicher, ob das so richtig passt. Nur auf der Südhälfte (bei Hausnummern 17, 19, 21) sind es teils wirklich vertiefte Basins, die Wasser halten könnten. Die Nordhälfte hat in meiner Erinnerung "herkömmliche" Grünflächen. Sicher haben die einen ähnlichen Zweck (wie vermutlich auch Temperaturregulierung), aber Basin finde ich semantisch schwierig. Allerdings bin ich in OSM wie gesagt nicht erfahren, ich versuche nur die Situation vor Ort zu schildern.
george1201 (2026-01-09 09:20:49+00:00): Mit dem Rendering von solchen Versickerungsbecken bin ich auch nicht zufrieden. Das sieht auf der Karte einfach falsch aus. Dort steht vielleicht einmal im Jahr für 3 Tage etwas Wasser, wenn überhaupt. Bei mir gibt es mit https://www.openstreetmap.org/way/1269313268 auch so ein Becken. Das habe ich in den vergangenen 15 Jahren noch nie mit Wasser drin gesehen. An der tiefstgelegenen Stelle vielleicht schon, aber sonst hat man dort keine nassen Füße bekommen. Und jetzt hat Scout_Jens gestern gar ein natural=water draus gemacht. 

Übers Rendering sollten wir hier aber nicht diskutieren, das müsste man an anderes Stelle (wie Forum) machen.

Zurück zum August-Klingler-Areal. Wenn ich eine Fläche vor Ort als Grasfläche wahrnehme, und erst nach einem Blick in die Baupläne sehe, dass es auch als Versickerungsbecken dient, dann plädiere ich dafür trotzdem ein landuse=grass einzutragen. Das ist für mich das OTG-Prinzip. Den weiteren Zweck der Fläche kann man gerne in der description eintragen.

Ja und die Spielplätze. Dort wo jetzt Spielgeräte stehen, sollte man einen playground-Knoten oder eine -Fläche eintragen (wenn man die Grenzen klar sehen kann). Der Playground darf auch über einer anderen landuse-Fläche (grass oder basin) liegen.
Radboss (2026-01-18 22:10:35+00:00): Wenn die Versickerungsfläche vor Ort nicht durch eine entsprechende Vertiefung als "basin" zu erkennen ist, dann würde ich auch für eine anderweitige Kennzeichnung plädieren. Zustimmung auch zum letzten Abschnitt bzgl. des Einzeichnens von Spielplätzen.
Halbtax (2020-10-15 16:31:10+00:00): Hi,

what is your source for your change. According to my information a maxspeed=250 was not approved by Swiss authorities.

Greetings
Halbtax (2020-10-29 13:03:06+00:00): Hi 

There seems to be no source for maxspeed=250.  I suggest to set the speed limit back to maxspeed=200 where there are verifiable sources. 

Best Regards
GartenStuhl (2020-10-30 13:43:58+00:00): Wenn man der Relation folgt -> Gotthard Basistunnel, dann auf den Wikipedia-Eintrag geht, steht da ja auch ganz klar, dass die Höchstgeschwindigkeit 200km/h beträgt... von daher sind die 250 bestimmt nicht richtig.
Ich werde die Bahnstrecken jedoch nicht editieren ;)
Piagno (2023-12-26 10:35:57+00:00): Auf 230 km/h angepasst. AB-FDV sind Referenz. Falls Geschwindigkeit erhöht werden sollte, wird dies in einer neuen Version der AB-FDV festgehalten.
https://www.openstreetmap.org/changeset/145527533
aixbrick (2020-06-28 11:59:31+00:00): Interessehalber: Wer nennt die Straße denn "WiBo"?
aachso (2020-06-28 16:15:12+00:00): Ich habe schon mehrfach Leute z.B. "in der WiBo" mit Bezug auf diese Straße sagen gehört. Kommt in Textform wahrscheinlich eher selten vor, weil man es dann doch eher ausschreibt. Allerdings benutzt Jonen auch "wibo" in der E-Mail-Adresse und Peer hatte auch "WiBo" in seinen Dateinamen hier verwendet: https://www.openstreetmap.org/note/2001976
aixbrick (2020-06-28 19:40:13+00:00): OK, ich kannte bisher nur Wirsingbongardstraße :-).
aachso (2022-06-13 23:23:11+00:00): Kurzer Nachtrag zur "wibo":

- https://www.dcm-emag.de/Bad_Aachen/2022-06/28/
- https://wirichsbongardstrasse.de/

;)
martinum4 (2020-06-27 23:15:44+00:00): Eine Source vergessen: DB Open Data für railway:ref und name von Hamm Süd RLG
eggie (2020-06-28 04:22:48+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.
Review.. Probeer als het even kan op de adresnode bij te taggen, 
MVG,
Eggie
eggie (2020-06-28 05:07:37+00:00): Het was hier al goed getagd op de adresnode. Je bijdrage heb ik weer verwijderd.
MVG,
Eggie
Open_fratt (2020-06-28 09:19:48+00:00): Hi Eggie. 

Thanks for the message. I am using the StreetComplete app for tagging and apparently it was not up to date. Since it asked me to add the name of the bar. 

By the way, I had also tagged the building next to it, which is not a restaurant but a private building.
eggie (2020-06-28 09:43:51+00:00): Oke.. thanks..   I removed the tag amenity restaurant with noname from the addressnode nr 45
Greetz,
Eggie
IgorEliezer (2020-08-31 23:32:53+00:00): Vias internas de condomínio fechado não são driveways (via de acesso a garagens e carga e descarga) mas vias residenciais com acesso "private", como essa https://www.openstreetmap.org/way/379862326.
AjBelnuovo (2020-09-01 00:10:31+00:00): Você já viu o resultado dessas " vias residenciais " aqui : http://qa.poole.ch/
IgorEliezer (2020-09-01 01:25:31+00:00): Vi. Algumas delas dão erro por falta de nome.
AjBelnuovo (2020-09-01 01:28:22+00:00): E todas vias de condominio se colocadas como vias residenciais darão .
IgorEliezer (2020-09-01 01:40:58+00:00): Mas são vias residenciais. E não é correto colocar vias residenciais como de serviço para fazer parar o erro.
AjBelnuovo (2020-09-01 01:44:11+00:00): Então alguém deveria lançar essa questão para discussão . 
Ficar com um mar de erros ? Não mapear , já que é uso restrito ? Ou qual solução .
IgorEliezer (2020-09-01 01:46:44+00:00): Complementando, o objetivo é mapear a realidade. Se são via residenciais que dão erro por falta de nome, precisa ou colocar o nome se tiver ou deixar sem se não souber, mas são residenciais. Não é correto mudá-las para serviço, pois isso só mascara o problema e aí fica difícil de encontrá-las para adicionar o nome por falta do alerta de erro de falta de nome.
AjBelnuovo (2020-09-01 01:52:45+00:00): Me desculpe , mas discordo que fique difícil de encontrar , já ninguém procura uma rua especifica para nomear .É só olhar o QA  para se ver o que falta nome e ver se a alguma fonte que lhe dê a informação .
Acho que deveria ter uma tag já definida pra isso ,
IgorEliezer (2020-09-01 01:55:44+00:00): > "Ficar com um mar de erros ? Não mapear, já que é uso restrito ? Ou qual solução."

Via residencial em que se precisa autorização para entrar, precisa acesso=private. Se você sabe o nome, coloque. Se não, deixe o campo "Nome" em branco.

Existir um mar de erros não é o problema, conquanto se está mapeando a realidade. 

Se você vê uma rua na imagem aérea mas não sabe o nome, mapeia-se a rua sem nome. Um dia, outra pessoa vai achar o erro de falta de nome e, se tiver o nome, ela coloca o nome; mas essa mesma pessoa não vai achar o erro se você converter tudo em via de serviço, que não requer nome só para evitar o mar de erros.
IgorEliezer (2020-09-01 01:58:53+00:00): Não é o nosso objetivo enganar os sites de validação. Nosso objetivo é mapear a realidade e o que temos conhecimento. Se você não tem conhecimento, não invente. Você sabe que a rua existe, mas não o sabe o nome, mapeia-se só a rua e deixe sem nome.

Você pode abrir uma discussão no grupo se quiser, mas já adianto que as respostas serão semelhantes.
AjBelnuovo (2020-09-01 02:03:25+00:00): Igor , não gosto do tom que escreve .Você não é dono do OSM .Quanto a abrir uma discussão, outro dia coloquei uma pergunta sobre o que fariam a respeito da alteração da ANP sobre gasolina . Ela ficou sem resposta .
Depois perguntei sobre o mapeamento de via reversível , a resposta foi a mesma . Silêncio . Que discussão se abriria sobre este tema ?
IgorEliezer (2020-09-01 02:26:22+00:00): > Igor, não gosto do tom que escreve.
Peço perdão pelo tom. Uma coisa é escrever no chat e fórum, outra coisa é escrever nessa caixinha apertada. Aí tenho se ser direto.
Acontece é que não é adequado converter vias residenciais em vias serviço pelo fato de não ter os nomes e para fazer aparecer menos erros nos validadores.

> Que discussão se abriria sobre este tema?
Então, você pode perguntar no grupo "é correto converter ruas residenciais em de serviço enquanto não tiverem nome para evitar aparecer erros?" só que eu acho que a resposta será negativa, porque há manuais apontando que isso não é adequado.
Quanto às vias reversíveis, vou responder no chat para não deixar um texto longo.
ftrebien (2020-09-02 02:06:29+00:00): É certo que não se deve mudar classificação simplesmente porque a via não tem nome. Eliminar os alertas corrigindo os dados é algo bom, mas eliminar um alerta que é um falso positivo só pra não ter mais o alerta é, no fundo, mapear para a aplicação (https://wiki.openstreetmap.org/wiki/Pt:Mapear_para_o_renderizador#Exemplos). Se a via realmente não tem nome (tem que conhecer bem e ter feito pelo menos um survey recente), usa-se noname=yes pra indicar que a via não tem nome mesmo. Agora se essas vias devem ou não ser highway=residential, é uma discussão que ainda náo foi muito aprofundada na comunidade brasileira do OSM. O consenso nas comunidades dos países da Europa e da América do Norte (que são os mais comuns em listas de discussão internacionais) é de que, pelo menos nas que parecem ruas comuns, seriam highway=residential. Outras que parecem mais estacionamento coletivo (geralmente em condomínios mais densos), geralmente (mas nem sempre) mais estreitas, talvez poderiam ser highway=service + service=driveway/parking_aisle/pipestem , mas essa é a minha opinião pessoal e não chegou a ser sacramentado nem no wiki, nem no fórum, nem em e-mails. O importante é classificá-las privilegiando a consideração da função principal delas. Em ambos os casos, devem ter access=private pra indicar que não são vias públicas. O wiki diz o seguinte: highway=residential é para ruas dentro de áreas residenciais que não servem à função de "passagem" (essas são no mínimo terciárias=coletoras), e highway=service é para vias de acesso a edifícios. O wiki usa como exemplo várias fotos, entre elas essa (https://wiki.openstreetmap.org/wiki/File:Apple_Garage.jpg), e nesse caso diz que service seria a via que vai da rua (parte inferior da foto) até a porta da garagem. Aqui (https://www.openstreetmap.org/?mlat=-23.09675&mlon=-47.17391) eu acho que as vias se assemelham bastante em aparência e função às dos condomínios fechados (https://en.wikipedia.org/wiki/Gated_community#Examples) americanos, como o Tuxedo Park (https://www.openstreetmap.org/relation/176082) e o Hot Springs Village (https://www.openstreetmap.org/way/33068277). Condomínios fechados são muito raros em países com menos desigualdade social como os europeus, e as raras opiniões que eu vi de europeus sobre esse assunto foram de que as vias de condomínios fechados (em referência às gated communities, geralmente com vias que parecem mais com ruas) deveriam ser highway=residential.
AjBelnuovo (2020-09-02 15:28:49+00:00): E qual é a diferença entre uma via num condomínio de " casas " e de um condomínio de torres de apartamentos ?
ftrebien (2020-09-03 18:48:58+00:00): Esse assunto ainda não foi discutido a fundo pela comunidade do OSM Brasil. Minha opinião pessoal é que as vias em geral (mas nem sempre) desempenham funções diferentes nesses dois casos. O consenso internacional é de que, pelo menos no condomínio de casas, as vias motorizadas de circulação interna devem ser highway=residential. Para o caso de condomínio de apartamentos, de alta densidade, que é bem mais comum no Brasil do que nos países que mais têm mapeadores, eu acho (pelos que eu conheço) que seriam poucas as situações em que as vias estão mais para highway=residential do que para highway=service. A alta densidade desses condomínios faz essas vias funcionarem mais como estacionamentos (cheios de entraves ao movimento dos vários modais) do que como as vias públicas comuns. Inclusive, em condomínios realmente grandes (muito raros), não é absurdo pensar que algumas dessas vias particulares poderiam ser terciárias (ou seja, análogas às coletoras públicas). Isso depende, em boa parte, do número de moradores do condomínio e da topologia das outras vias dentro dele, e também depende do consenso dos mapeadores locais. Uma situação parecida é a dos grandes parques industriais, onde algumas vias excepcionalmente importantes, mesmo que particulares, poderiam ser análogas às coletoras, enquanto a maioria das grandes vias de circulação interna seriam mais como highway=unclassified. highway=service, nessa situação, seriam as pequenas vias estreitas, como as que dão acesso às garagens nos exemplos do wiki, ou como o exemplo de service=alley. Quando falta consenso, é necessário comparar, ver como é feito nos outros lugares, propor critérios mais objetivos se achar necessário (com exemplos), etc.
AjBelnuovo (2020-09-03 19:36:42+00:00): Há  previsão deste assunto entrar em discussão na comunidade OSMBrasil ?
pio2_122 (2020-06-28 11:00:20+00:00): Jaki jest powód zmiany kategorii dróg?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/87238007
Robercin (2020-07-01 19:45:21+00:00): Chęć odwzorowania ich parametrów technicznych w układzie całej sieci (nie podałeś o które konkretnie odcinki dróg pytasz).
pio2_122 (2020-07-01 19:55:05+00:00): Chodziło mi o wszystkie zmienione drogi, których kategorie zostały zmienione.

Od parametrów technicznych są przede wszystkim tagi surface i smoothness, tracktype, czy width.
Kategorie dróg mają głównie za zadanie oddać stopień istotności dróg w sieci drogowej.
Źródło: https://wiki.openstreetmap.org/wiki/Pl:Key:highway
Robercin (2020-07-01 20:25:43+00:00): Wiele jeszcze lat upłynie, zanim programy nawigacyjne będą te wszystkie szczegółowe tagi interpretować, zamiast brać pod uwagę wyłącznie kategorię drogi...
Warto również mieć cały czas na uwadze, że ów stopień istotności dróg w sieci drogowej jest także nierozerwalnie związany z parametrami technicznymi danej drogi w porównaniu z parametrami technicznym innych dróg na danym obszarze.
Robercin (2020-07-01 20:44:30+00:00): "Wartość znacznika highway powinna odzwierciedlać rzeczywistą funkcję i znaczenie drogi. W związku z tym nie powinna być ustalana w ścisłej zgodzie z oficjalną, urzędową klasyfikacją dróg."
"Klasyfikacja urzędowa może pełnić funkcję pomocniczą, ale nie decydującą przy ustalaniu wartości znacznika highway."
pio2_122 (2020-07-01 21:09:15+00:00): Najpopularniejsza w Polsce nawigacja korzystająca z OSM (Yanosik) już to robi! - Na pewno bierze pod uwagę te najważniejsze, czyli tracktype i surface. Nie prowadzi w ogóle po drogach typu track. Stąd ważne jest aby wszystkie podjazdy do zabudowań były otagowane jako service (dodatkowo z tagiem surface), ponieważ jeżeli podjazd będzie trackiem to nawigacja doprowadzi tylko na wysokość celu na drodze o wyższej kategorii. Wtedy może wydarzyć się sytuacja, że dostaniemy komunikat "jesteś u celu", a tego celu nie będzie nawet widać, mimo że droga dojazdowa (track) jest dociągnięta pod sam adres. Jest naprawdę sporo adresów mocno oddalonych od głównych dróg, także to nie jest jakiś wymyślony problem.

Inne nawigacje mają opcję "unikaj dróg gruntowych" - wątpię aby wykluczały one tylko tracki. A nawet jeśli tak jest, to wydarzy się ta sama sytuacja, którą opisałem wyżej - nawigacja doprowadzi tylko do najbliższej drogi o kategorii wyższej od track.

Wszystkie potrzebne tagi są już szeroko używane w OSM i jak widać można je wykorzystać.. Także argument odnośnie nawigacji jest nietrafiony...

Jeszcze dobry argument z wiki za  highway=service "Note that driveways are defined by their function, not a quality. Driveways may have various quality - from surface=asphalt through surface=compacted to surface=sand."
pio2_122 (2020-07-01 21:11:11+00:00): Nigdzie nie wspominałem o powiązaniu kategorii dróg w OSM do tej urzędowej... Także nie wiem co ma oznaczać ten cytat z wiki...
Robercin (2020-07-01 21:52:16+00:00): Dziękuję za rzeczowe informacje.
Pisałeś o "stopniu istotności dróg w sieci drogowej", a ma on wszak dość istotny związek z kategorią dróg w hierarchii, dlatego to przytoczyłem.
Odnośnie zmian wszystkich dojazdów do nieruchomości ("podjazdów") na kategorię service, to całe lata pracy żeby to wszystko przerobić, a jak rozumiem, miałoby się to dokonać jednocześnie z oznaczeniem wszystkich dróg dojazdowych prowadzących do wszystkich nieruchomości kategoriami co najmniej jako residential bądź service, z odpowiednimi szczegółowymi tagami...
maraf24 (2020-07-01 22:03:09+00:00): "Wiele jeszcze lat upłynie, zanim programy nawigacyjne będą te wszystkie szczegółowe tagi interpretować, zamiast brać pod uwagę wyłącznie kategorię drogi..."

Te wiele lat upłynęło gdzieś tak 4-5 lat temu, więc jesteś mocno nieaktualny. I to samo dotyczy wielu z tych zmian.  Jak je widzę, to mam wrażenie, że jest rok 2015.