piebro/osm-data huggingface dataset:
gscholz (2019-09-28 07:08:33+00:00): Hi Nik,
some of your recent edits have created a lot of errors in the osm database:

http://tools.geofabrik.de/osmi/?view=areas&lon=-55.37702&lat=-22.38007&zoom=11

Are you interested in fixing these?
Kind Regards
Guido
NikAlmino (2019-10-04 09:43:32+00:00): I am aware of the errors and will try to correct them in the next changeset.
kartonage (2019-07-03 20:37:17+00:00): Hallo SteMue,

die Finanzierungsvereinbarung wurde erst letzte Woche unterschrieben, sodass Planungen entsprechend erst jetzt beginnen. Gebaut wird laut Einschätzungen eventuell erst ab 2021. Ich bitte dich also diese Eintragungen wieder rückgängig zu machen. Planungsdaten ohne entsprechende Quellenangabe in OSM als aktiven Baustand zu übernehmen ist auch nicht erwünscht.

Schöne Grüße
SteMue (2019-07-08 17:34:58+00:00): Die Bahntrasse ist derzeit ein Wohngebiet?
Das kann ich nicht zwar nicht ganz glauben, aber Sie sind der Chef.
SteMue (2019-07-14 05:08:18+00:00): Das ist OSM, kartonage ist ein typischer Fall.
Ich übergebe es ins Forum, wo wahrscheinlich auch nichts passiert.
kartonage (2019-07-14 05:15:45+00:00): Hej SteMue,

ich weiß nicht, was du mit deinen Kommentaren ausdrücken willst. Du hast dich auf irgendwas unbestimmtes bezogen und bist nicht auf das Grundproblem eingegangen. Du hast die Planungen als aktive Trassenbaustellen eingetragen. Von dir wurden weiterhin auch keine weiteren Quellen oder Informationen erbracht. 

Schöne Grüße
PT-53 (2019-07-14 05:29:26+00:00): Hej SteMue,
es wäre schön, wenn Du sachlich bleiben und auf die Anmerkungen von kartonage konkret eingehen würdest. So kommt mir nur der Spruch "getroffene Hunde bellen" in den Sinn.
Grüße
SteMue (2019-07-22 08:59:46+00:00): Ist eine Bahntrasse ein Wohngebiet, ja oder nein?
Die Frage hat weder etwas mit Bellen noch mit Treffern, noch mit Hunden zu tun. 
Wenn wir bei Spitzfindigkeiten bleiben, wäre es ja auch möglich gewesen, das Attribut Construction wieder in disused zu ändern und nicht den ganzen Bearbeitundsatz in so einer selbstgerechten Art auf den  Müll zu werfen. 
Neben, Quatsch, selbstgerecht ist schon okay!
Nakaner (2019-07-22 10:16:21+00:00): Hallo SteMue,

was bedeutet eigentlich "LUBI", das du als Quelle angibst?

Viele Grüße

Michael
SteMue (2019-07-26 06:57:27+00:00): Hallo Michael, LUftBIld.....
Leo Slager (2019-07-04 23:19:31+00:00): Je hebt met het knippen van rotondes weer een tiental busroutes beschadigd.
Als je zonodig rotondes wilt knippen zou het wel zo netjes zijn als je de routerelaties die je beschadigd ook weer repareert. Overigens is het knippen van rotondes een volkomen overbodige handeling, zeker als je daarmee alleen maar schade berokkent aan andere routes.
Als je wilt weten welke buslijnen er nu beschadigd zijn, kijk dan even hieronder.
Het zijn 18 routerelaties die gerepareerd moeten worden.
Sint E7 (2019-07-05 17:09:10+00:00): Ik kom ze toch wel tegen; ik loop deze concessie helemaal na en ik pas alle buslijnen aan aan de werkelijkheid. Niet alleen in deze concessie, maar in veel meer concessies ligt zo'n achterstand en die ga ik nu maar eens wegwerken.
alphensebezorger (2019-07-05 17:52:56+00:00): Als je een weg gaat splitsen, kun je het beste ervoor zorgen dat je de vorige en volgende weg in de aanwezige routes eerst download in JOSM. Dan zorgt JOSM ervoor dat de nieuwe weg op de juiste plaats in de relaties terecht komt. Zo bespaar je jezelf of een andere mapper een boel onnodig herstelwerk.
Het eenvoudigst gaat dit door de weg die je gaat knippen te selecteren, op 3 te duwen op je toetsenbord om erop in te zoomen, en vervolgens "Download data" en enter indrukken.Die stappen kosten veel minder tijd dan het herstellen van sorteerfouten.
Hier geldt volgens mij: voorkomen is beter dan genezen.
Leo Slager (2019-07-05 22:22:06+00:00): Mijn ervaring is dat één van de twee routes altijd wordt beschadigd. De route die in dezelfde richting loop als de highway wordt niet beschadigd. In de andere route staan de twee delen van de geknipte weg in de verkeerde volgorde.
Bij het opknippen van rotondes blijven alle delen in de route staan en zijn dus altijd alle routes beschadigd.
Leo Slager (2019-07-06 08:26:46+00:00): En dan te bedenken dat het opknippen van de rotonde volledig overbodig is.
alphensebezorger (2019-07-06 10:39:48+00:00): Ik heb het net nog eens geprobeerd in JOSM. Eerst zonder uiteindes van de weg in het downloadgebied, daarna met extra download rondom die twee punten.
Zonder de uiteindes zie ik wat jij beschrijft: als de route tegen de richting van de weg inloopt, krijg je een sorteerfout.
Zodra ik eerst download rond de uiteinden van de weg (die ik daarna ga knippen), krijg ik geen enkele sorteerfout meer.

P.S. Als iemand toch sorteerfouten krijgt bij knippen, terwijl beide eindpunten in het downloadgebied liggen, ontvang ik graag een .osm-file waarbij dit gebeurt.
rivermont (2019-08-24 20:41:52+00:00): Hi avelex,
Please be careful when mass editing things, especially in JOSM. In this changeset you added `parking:lane:both` tags to hundreds of child nodes. This tag is intended ONLY for the roads it applies to, not the nodes making up the road.
If you could correct these changes that would be great.
Let me know if you have any questions.
Thanks,
Will
andi9876 (2019-07-04 06:53:51+00:00): Dear, please stop unaligned roads.
https://drive.google.com/file/d/1P5YIi5b4a40o8VnR0L8ta1Dpesxverq_/view?usp=sharing
andi9876 (2019-07-04 06:56:49+00:00): reverted
(Inactive) Hoordinates (2019-07-04 17:00:41+00:00): Hello andi, sorry for the misalignment. My imagery must have been off. Thank you for correcting this and I will be much more careful in the future.
pitscheplatsch (2019-07-04 11:23:50+00:00): Hi AVKerova, welcome to OSM.

May I know the reason behind reverting your own changesets? Thanks.

--- 
Detected by #SuspiciousOpenStreetMap
TravGW (2019-07-03 23:06:57+00:00): Not a park
TravGW (2019-07-03 23:07:04+00:00): Not a church
pitscheplatsch (2019-07-04 11:11:43+00:00): Hi seyahmit, welcome to OSM.

May I know the reason behind deleting several mapped wood areas which are visible in the utilized satellite imagery? Thanks.

More information about your changeset: https://overpass-api.de/achavi/?changeset=71875293

#GolfMapping
#Vandalism
--- 
Detected by #SuspiciousOpenStreetMap
Hjart (2019-07-03 21:30:18+00:00): What makes you think it's no longer oneway? It was made oneway 4 years ago: https://www.openstreetmap.org/changeset/31633779 
I spoke to the guy on several occasions and he appeared quite serious.
Hjart (2019-07-03 21:35:03+00:00): To determine whether it was really no longer oneway, you would look for a sign like the one in https://www.mapillary.com/map/im/fMeH2YS6fzX1EVCqehBxVQ at the other end
Bulls_eye (2019-07-04 00:00:38+00:00): Hello Hjart,

I removed the oneway tag based on the presence of the yield sign visible in [Mapillary] (https://www.mapillary.com/app/?lat=56.344307391&lng=10.45704664660002&z=17&pKey=L5Cqsmb2H6yYhUVcDOWg-w&focus=photo&x=0.39926554068498166&y=0.4854974861217911&zoom=0). Since the sign is oriented to the north, it seemed logical to me that traffic was expected to come from the north (opposite the oneway). Unfortunately, the Mapillary coverage in this area is a bit sparse, but I did check the surrounding area for explicit oneway or do not enter signs and could not find any. Do you have any tips that could help in these situations?

Thanks,

Bulls_eye
Hjart (2019-07-04 06:19:15+00:00): That yield sign could be a leftover from before it was made oneway 4 years ago. I would definitely leave it oneway until I had more solid proof (Mapillary coming from the north) that it's no longer oneway. The comment of the changeset adding the oneway says it's no longer legal to enter Thorsgade from Vestergade.
Hjart (2019-07-04 06:39:55+00:00): I've readded the oneway tag. I remember noticing when it was first added and it did appear quite legit.
Did you check the history of the road before removing the oneway tag btw?
Bulls_eye (2019-07-04 19:25:44+00:00): Hey Hjart, yeah I checked history but the mapillary is more recent so I added oneway. Because mapillary also is not recent, I’ll defer to your local knowledge. Thanks for following up.
sovereign_ch (2019-07-04 13:09:24+00:00): Auch hier der freundliche Hinweis, das wiki zu konsultieren, bevor irgendwelche von iD vorgeschlagenen Änderungen übernommen werden. Es ist ohnehin schon zu viel redundant eingetragen.

Auch die Löschung der älteren PTv1-Platformtags, auf welche u.a. Mapnik angewiesen ist, ist höchst destruktiv.

Die verhältnismässig neuen Tags 'departures_board' (im ZVV ist 'timetable' Minimalstandard) und 'passenger_information_display' (elektronisches Display, wo vorhanden) sind so weit in Ordnung.
JessAk71 (2019-07-04 17:28:23+00:00): Hi avelex_lyft,
Looks like that tag you removed is only misspelled because it has a 's' on 'lane' so you could change 'parking:lanes' -> 'parking:lane' instead and it would then conform to the standard here: 
https://wiki.openstreetmap.org/wiki/Key:parking:lane this may be the best approach to avoid deleting relevant data for all these streets...
avelex_lyft (2019-07-08 17:22:14+00:00): Thank you so much for bringing that to my attention. I was not intending to delete them but merely to fix the spelling. You are correct, and the tags have been added to the ways.
Leo Slager (2019-07-04 10:37:35+00:00): review:
Netjes gedaan.
De twee gewijzigde gebieden liggen echter ver uit elkaar. Het schuiven met de kaart in de edit-modus veroorzaakt vaak ongewilde beschadigingen. Het is dus beter om dit in twee changestets te doen.
Leo Slager (2019-07-04 10:42:21+00:00): De naam en adres-gegevens staan nu 2 maal op de kaart. Gebouwen worden in NL rechtstreeks geîmporteerd vanuit het Kadaster. Dan wordt er ook een nofe aangemaakt met de adresgegevens.
Adressen worden dus niet op de gebouwen getagd. Bedrijfsgegevens of naam wordt dan ook bij voorkeur bij getagd op de adresnode.
ik pas even wat aan.
Besselking (2019-07-04 10:55:08+00:00): Dank je wel voor de review en opmerking Leo, ik zal het de volgende keer in de gaten houden
emvee (2023-07-30 11:19:50+00:00): Bonjour,

Dans ce jeu de modifications, vous avez remplacé maxtents=X par tents=X.

Aujourd'hui, capacity:tents=X + tents=yes est utilisé pour cela, voir https://wiki.openstreetmap.org/wiki/Key:maxtents.

Que diriez-vous de changer à nouveau cela en capacity:tents=X + tents=yes ?

Emvee.

NB: Translated into French using deepl.com
frosm (2023-07-30 12:44:58+00:00): I see no added value from switching from tents=number to tents=yes capacity:tents=numbers but indeed https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site advicee that and I see that you are mass changing this tag
due to the number of objects in France,  i'lll open a thread first
emvee (2023-07-30 13:36:44+00:00): No, I did not mass change things, I did update about 15 campings one by one. Now only camp site in France are left and before changing those I did contact you.

Before that there were 109 campings mapped with tents=\d+ and capacity:tents was used 870 times.

Can you include me on the thread?
emvee (2023-08-05 20:21:28+00:00): Did you open a thread?

Any conclusion?
emvee (2023-08-20 15:23:24+00:00): Just to let you know, unless I hear something I will likely change somewhere next week the campings that in this changeset were changed from maxtents=X par tents=X into capacity:tents=X + tents=yes
frosm (2023-08-20 16:37:43+00:00): feel free, you only need to follow https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
emvee (2023-08-20 18:34:30+00:00): Interesting, searching the tagging list I found:

https://lists.openstreetmap.org/pipermail/tagging/2019-August/047624.html

So then there were 3 proponents of capacity:tents=<number> and 2 proponents on tents=<number>

So, when you did your/this "automated edit", based on what did you change maxtents=<number> into tents=<number>?
emvee (2023-09-03 14:41:55+00:00): Also interesting you remember me of the Automated Edits code of conduct, did you yourself follow it? I searched for some evidence but could not find anything.

Reading the wiki I read: "without review individually by the person controlling the edits" and that is not what I am planning to do.
Aleksa M (2019-07-05 10:54:19+00:00): Desio se neki problem izgleda kada si stavio sve radnje u odnos. Ne prikazuje se više tlocrt zgrade.
Branko Kokanovic (2019-07-05 13:15:10+00:00): da, vidi stvarno. Bilo mi nesto cudno u JOSM-u, da je napravio multipolygon, a na relation kako treba, ali nisam pridavao paznje mnogo. Pogledacu veceras kad dodjem kuci
Branko Kokanovic (2019-07-06 07:47:36+00:00): Mislim da sam ga sredio, ali proveri ti svejedno:D
Aleksa M (2019-07-06 08:49:22+00:00): Jesi, sad je super. Samo ću još da dodam shop=mall, pošto to sad fali.
Aleksa M (2019-07-06 08:51:17+00:00): Ti si to stavio na odnos, a treba i na samu zgradu.
Branko Kokanovic (2019-07-06 10:11:05+00:00): Da, da, hvala, prepravi ti sve što misliš, verujem više tebi nego sebi:)
Aleksa M (2019-07-06 11:08:46+00:00): Haha, hvala.
Kovoschiz (2019-07-04 09:46:06+00:00): There are many mistakes here. Do you have any experience with HK before? 
1. A guideline in HK is that `motorway` follows Expressway area, and `trunk` follows Strategic Routes. Your edits fail to follow this principle. 
2. Before Route 10 is implemented, these will not be `trunk` by virtue of road function either. 
3. Shun Long Road can't possibly have two southern main lines. It's clear one is a forking bypass, and the other a reverse branch.
Kovoschiz (2019-07-07 14:50:26+00:00): https://www.openstreetmap.org/changeset/71984160
BCNorwich (2019-07-04 06:31:14+00:00): Hello and Welcome to OpenStreetMap.

I've amended the garages and soccer area tagging to suit OSM practice. Removed the pitch from adjoining the residential area outline. Removed an untagged line inadvertently added.

Regards Bernard.
pitscheplatsch (2019-07-04 10:50:25+00:00): #test #failed

Please don't add test data to the live OSM Server. 
If you want a test server, perhaps http://api06.dev.openstreetmap.org/ would work for you? Furthermore, can you revert your edits?

--- 
Detected by #SuspiciousOpenStreetMap
MKnight (2019-10-20 10:41:12+00:00): revertiert in #75949884
Hjart (2019-07-03 22:43:25+00:00): Scherfig Hus var i forvejen navngivet: https://www.openstreetmap.org/relation/7398058/history (på multipolygonen), så derfor har jeg fjernet det navn du angav.
Hjart (2019-07-04 10:57:06+00:00): Doesn't appear possible to drive through that wall, so I've reworked the area further.
Cumin_bean (2019-07-04 19:58:38+00:00): Thanks! I appreciate it.
dmlu (2019-07-05 10:41:07+00:00): Hi, are you sure this is on the right location?
Hjart (2019-07-04 10:37:20+00:00): This looks like a mistake. Why did you remove this path?
GeoidDude (2019-07-04 20:05:00+00:00): Hi Hjart,

I was looking at SDFE Skraafoto. Upon further investigation I can see that this is still blocked to vehicle traffic. I will change it back. Thanks!
jc86035 (2019-07-21 09:52:12+00:00): Hi, note that you seem to have introduced a lot of rendering issues with these changesets (for example, there are now a lot of superfluous railway=station nodes, and this changeset removed the station label for the mainline Siu Hong station). Tram stops should not need railway=station or railway=halt, to my knowledge, although I might be wrong.
Diego Sanguinetti (2019-07-21 17:45:29+00:00): Hello and I am sorry about this inconvenient. First, there are 12 HK light rail routes and I had to assign as such (from https://en.wikipedia.org/wiki/Light_Rail_(MTR) ). Second, when I was switching to light rail I had to add stations (I did not find an explanation like using a light rail line without the railway=station tag). And three, I noticed that maps.me is implementing its public rapid transit system, I show you the documentation on Github (https://github.com/mapsme/subways).

For now I keep it as a light rail, unless you suggest how to solve the rendering problem you have indicated. Maybe I could change the tram stops to light rail stops. Thank you.
jc86035 (2019-07-21 17:55:35+00:00): What did you have to "assign as such"?

I'm not sure if this is a translation issue, but outside Europe a "light rail" is usually a medium-capacity tram system. This is partly why I chose to use railway=tram_stop (there is no such thing as a railway=light_rail_stop, to my knowledge); it seems to be used in a very similar manner in e.g. Paris. If changing it to tram=yes would be more accurate (I think this would be technically appropriate, since light_rail=yes refers to S-Bahns in Europe) then I would be fine with that, although a wider discussion than on this changeset would be necessary.

If public_transport=station is necessary for the validator to stop complaining, I am not opposed to adding it to the stop area relations; however, I think railway=station would be inaccurate, and on the osm.org map it's visually confusing because the tram_stops are already rendered.
jc86035 (2019-07-21 17:56:52+00:00): I am still not sure why you removed the railway=station tag from the Siu Hong station building and added a railway=station node with no name tags, though. It was presumably fine before; or is that usage incorrect?
Diego Sanguinetti (2019-07-21 18:02:40+00:00): An additional note, I checked this at https://wiki.openstreetmap.org/wiki/Tag:railway%3Dtram_stop This page says that (in summary):

"This tag (stop_tram) is used [on] light rail tracks (railway=light_rail) where the halt ressembles more a tram stop than a railway halt (railway=halt)."
jc86035 (2019-07-21 18:05:03+00:00): I don't think it's supposed to be used at the same time as railway=halt or railway=station, though.
Diego Sanguinetti (2019-07-21 18:10:41+00:00): Now, if you're referring to the Siu Hong station node, I think that separate one node for the light rail station and another for the MTR subway. It is right?
jc86035 (2019-07-21 18:16:36+00:00): I haven't really edited for a while, but I would have one node/way for the commuter rail station (Siu Hong station) and follow whatever the tagging convention is supposed to be for the light rail station (Siu Hong stop). I think it would probably be four nodes with both railway=tram_stop and public_transport=stop_position if the station is classified as a tram stop (for platforms 1–2 and 5–6, since the other two are not in service). This is my guess, though, and I'm not totally sure if this would be correct. What would the validator software say if you did this?
jc86035 (2019-07-21 18:17:40+00:00): (As noted, if the software really wants a public_transport=station, it probably shouldn't be rendered since the stop positions already have labels.)
Diego Sanguinetti (2019-07-21 18:27:25+00:00): Well, I'll tell you how the validator works. First assign the stops (stop positions) of the route (either light rail or subway, since for now it is only validating this type of routes of the MTR, like this list in Wikipedia https://en.wikipedia.org/wiki/MTR#Rail network). Then verify if each stop is assigned to a station (both the stop node and the station must be in a stop area relation). If each stop is not assigned to a station, it shows an error.

In addition, it is advisable to add stops and platforms to the stop area relation (whether this is operative or no, to avoid an error when it is in operation, when is adding a new route, in the future).
jc86035 (2019-07-21 18:29:41+00:00): Okay. In that case, I would remove railway=station from the Light Rail public_transport=station nodes, re-add railway=station to the MTR West Rail Line stations, and remove any railway=station without labels. I would probably do the same for tram networks in other cities.
jc86035 (2019-07-21 18:30:24+00:00): Presumably the validator will still be fine with this, since it should only check the public_transport=* tags?
jc86035 (2019-07-21 18:32:27+00:00): * "remove any railway=station without labels": this is incorrect; for Siu Hong station specifically I would re-add railway=station and public_transport=station to the station building, and remove the node without any name tags from the commuter rail station's relation.
jc86035 (2019-07-21 18:33:48+00:00): Unless the validator does not like railway=station/public_transport=station on ways; in that case I would move the tags from the station building to a new public_transport=station node (and so on).
Diego Sanguinetti (2019-07-21 18:37:24+00:00): Right, that's what I can explain to you. (I clarify that I am not the creator of this validator. However, when I found the error "stop node #### is not connected to a station on the route" I had to investigate the reason for this problem in this Github repository and more). I recommend that you send a message to https://www.openstreetmap.org/user/Claudius%20Henrichs, he knowns this mechanism better. Also, he can report any inconvenience to maps.me developers.
Diego Sanguinetti (2019-07-21 18:44:01+00:00): Meanwhile, I'll be waiting to find some error. Also, this is the page that indicates if there is a error in the Hong Hong routes from this validator. The results are updated about 3 times a day. http://osm-subway.maps.me/china.html
Diego Sanguinetti (2019-07-21 18:44:38+00:00): Thank you for your fast reply.
5m4u9 (2019-07-05 03:33:47+00:00): hola, la cancha modificada ya estaba actualizada a la ultima imagen satelital MAXAR
ToniE (2019-07-04 07:52:39+00:00): Hi k127,

Danke für's Hinzufügen weiterer Bus-Relationen.
Die Gegend dort ist in OSM wirklich noch sehr unterentwickelt was ÖPNV angeht.

Eventuell interessiert Dich:

https://ptna.openstreetmap.de

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-RBO-Analysis.html

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-RBO-Analysis.diff.html

https://wiki.openstreetmap.org/wiki/Ostbayern/Transportation/Analyse/DE-BY-RBO-Linien

Viele Grüße
Toni
k127 (2019-07-04 12:34:10+00:00): Hallo Toni,

cool, danke für diese Validierungsstellen, die hatte ich bisher nicht auf dem Schirm und stattdessen mit JOSMs PT-Plugin geprüft.

Die in PTNA genannten Fehler betrachte ich bis auf weiteres mal als *false positives* (`fixme` dürfte eh klar sein, `network` steht im Route-Master).
Einzig die Fehlermeldung „Mehrere Routen aber kein Route-Master“ erklärt sich mir nicht ganz. Hättest du dazu 'ne Einschätzung?

Cheers
Klaus
ToniE (2019-07-04 12:53:29+00:00): Hallo Klaus,

'fixme', 'note' usw. sind schlichtweg unter der Kategorie "Fehler" aufgelistet, da sie ja auf Fehler hinweisen sollen.

'network' und so weiter ... viele Dinge sind im PTv2-Proposal als 'optional' oder 'recommended' definiert. Es hat sich aber gezeigt, dass z.B. "Sketch-Line" (Overpass-Tool) einige Dinge als 'mandatory' erwartet um gescheit funktionieren zu können. "Sketch-Line" kennt PTv2 (insbesondere "route_master") nicht, benötigt aber den Wert des 'network'-tags

Insgesamt ist das PTNA Tool an vielen Stellen puristischer als das PTv2-Proposal und macht oft 'optional' und 'recommended' zu 'mandatory', dort wo es Sinn macht und die REdundanz eine gescheite Qualitätssicherung unterstützt.
Ich selber bin kein Fan von 'minimalistischem Mappen' sonder eher von Redundanz.

Das PTv2-Proposal (https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726) sagt, dass bei mehr als einer Route-Variante, alle type=route Relationen in einer (Sammel)-Relation type=route_master, route_master=bus (z.B.) zusammengefasst werden sollen.
Z.B.: Bus 6120  https://www.openstreetmap.org/relation/9748935
den Du ja vor 13 Stunden  erfasst hast. Warum der allerdings angemeckert wird, weiß ich grad' nicht, warten wir mal moregan ab.

BTW. bzgl 'source = http://www.vlp-passau.de/fileadmin/user_upload/Linienfahrplaene/Fahrplanaenderung_zum_01.03.2019/6120_beide_99.pdf '
Bitte stelle sicher, dass Du hier kein Copyright verletzt. Wenn der VLP nicht die Erlaubnis gegeben hat, dann dürfen wir die Infos nicht benutzen.

Siehe:

MVV und https://wiki.openstreetmap.org/wiki/Contributors#Bayern 

und

https://wiki.openstreetmap.org/wiki/DE:Permissions#ab_2019

Viele Grüße
Toni
ToniE (2019-07-05 07:09:40+00:00): Hi,

der route_master tauchter in der Analyse von RBO nicht auf, weil 'network=...VLP' gesetzt war, und RBO nicht enthalten ist.

Ich habe nun 'network', 'network:short', 'network:guid', operator' und 'operator:short' angeglichen und überall gesetzt.

VG
Toni