Geen idee.

het lijkt mij een substation dus dat heb ik er nu neergezet

hallo,

Ik heb er even naar gekeken en ik zie twee dingen. "officeel" gezien is crossing_ref=delineated goed maar ik zie ook dat er langzaam een consesus ontstaat dat we het crossing schema moeten versimplen. osm.wiki/Tag:crossing_ref=delineated

ding twee is dat tehcnich gezien SmotheFiets de crossing_ref heeft toegevoegd en ik de dashes.
https://osm.mapki.com/history/node/46934703

van mij mag het maar ik ben natuurelijk niet de baas van osm.
Als je echt zeker wil weten dat iedereen het er mee een is moet je dit opgooien in de OSM forum

Naar mijn ervaring zij 90% van de correcties correct en zijn er inderdaad nog 10% waar een fout in staat.

Als ik dan hier op aangesproken wordt zorg ik dat de NSI wordt geupdate.

Ik ben het met je eens dat multivlaai waarschijnlijk beter onder shop=pastry lijkt te vallen.

Breng of Hermes lijkt een grotere discussie te zijn. het is namelijk Hermes die onder de merknaam Breng rijd.
https://wiki.ovinnederland.nl/wiki/Concessie_Arnhem_Nijmegen_(2013-2026)

dus ik vind dat de operator Hermes is en dat de fout hier is dat er geen brand is toegevoegd is.

ik hoor graag wat je ervan vindt voordat ik een verandering naar NSI opstuur

ik heb hier even naar gekeken. ik had al een update naar NSI gestuurd voor alle concessies dus dit moet als ID geüpdatet is weer goed komen.

Ik zal proberen beter op te letten tijdens het editen. Maar er is natuurlijk veel te onthouden over osm en vaak zal mij iets ontglippen.

Een andere afweging die ik vaker maak is tussen kwaliteit en kwantiteit.
ik kan binnen een dag alle ID problemen in een middelgrote stad opgelost hebben, of ik kan een winkelcentrum updaten.
zeg maar wat belangrijker is.

Dus net als iedereen probeer ik altijd het best mogelijke werk te leveren.

We have seemed to stumble upon an error in the NSI.

I've submitted a fix to the NSI.

I also want to apologize for the error. I lean on the NSI to make many quick edits, and most of the time, this has great results. But sometimes there is an error, and I don't notice it.

https://github.com/osmlab/name-suggestion-index/pull/9960

ik heb hier even naar gekeken en het komt door dat nsi het verkeerd heeft gecorigeerd.

Ik heb een correctie op gestuurd naar nsi

https://github.com/osmlab/name-suggestion-index/pull/9745

ps. dat ik het daar zelf verkeerd heb toegevoegd zal ik er maar even niet bij zeggen

Hallo,

Excuus voor het niet tijdelijk beantwoorden van de vraag. Voor dit antwoord moest ik diep de staatscourant in.

Dit antwoord bestaat uit drie vragen.

Is het een militair oefenterrein?
Is de tagging goed?
Hoe ziet het er uit op de kaart?

De originele reden dat ik dit gebied heb aangemerkt als militair terrein is omdat hij voor kwam in Regeling algemene regels ruimtelijke ordening. Wat de wet was voor het aanmerken van dingen als oefengebied.

https://wetten.overheid.nl/BWBR0031018/2021-07-01/0/#:~:text=Kaart%20militair%20terrein%20%E2%80%93%20oefenterrein%20De%20Dellen

Nu is deze wet recent vervallen en was het even zoeken welke wet dat nu doet. In deze zoektocht ben ik uitgekomen op de Omgevingsregeling.

https://wetten.overheid.nl/BWBR0045528/2024-01-01

Deze verwijst weer door naar Geometrische begrenzing militaire terreinen en terreinen met een militair object. Wat een Geography Markup Language file is met alle militairen gebieden in nederland

https://zoek.officielebekendmakingen.nl/dc-2019-141/1/html

Tot zover mijn bronvermelding. Want we waren het al eens dat het een militair oefengebied is.

Dan voor de tagging. landuse=military wordt beschreven als

An area used for any military purpose, with additional tags used to describe what that purpose is.

Deze additional tags in dit geval is military=training_area. Wat dit als oefengebied aanmerkt.

Het enige wat ik nog zou kunnen aanmerken op de tagging is dat er iets van een access tag bij kan om aan te geven of dat het een open of dicht oefenterrein is.

Als u het met de bovenstaande antwoorden eens bent dan hebben we als laatste nog de render.
Ik wil niet met osm.wiki/Tagging_for_the_renderer gooien... maar het is een militair oefenterrein en hij is goed getagd. Dan is het in dit geval een “fout” in de render. Het zou onwaar zijn om dit geen militair oefenterrein te noemen.

Ik ben het met u eens dat de rode strepen op de kaart vaak aangeven dat je er als burger niet mag komen. Maar de render moet in dit geval dus het verschil maken en niet de tags.

Ik hoop dat ik hiermee antwoord gegeven heb op uw vragen. Ik sta open voor meer correspondentie.

- wvdp

Let me first say that in this case, you are right. And for me, this is a bad hill to die on. But...

Although in general, it is the case that we put the poi on nodes, it's not always the way that we do it. When there is a clear area that is all part of the poi, think de Efteling or Shell Pernis then it is reasonable to create an area to represent the poi.

So, in this case, I will move the information back to the node. because the outline is not specific. But when there is a clear outline of the area of the data center then I will still use that.

je hebt mij in een moment van zwakheid gevonden.

ik weet hoe het moet. maar soms is het makkelijk om er gewoon iets in te plakken.

ik heb het nu goed gedaan

ik kan mij deze edit niet activef herinneren maar op wikipedia staat deze naam vernoemd zonder bron.

zelf ben ik van bron gewisseld en noemd de wet die hier over gaat het ook munitieopslagplaats MMC Veenhuizen.

dus ik denk dat aan gebrek aan een beter bron de naam veranderd mag worden.

https://wetten.overheid.nl/jci1.3:c:BWBR0031018&bijlage=12.25&z=2021-07-01&g=2021-07-01

je kan not:brand:wikidata=Q287471 gebruiken als dit vaker gebeurd.

ik heb het toegevoegd.
excuus voor de edit

de challange gaat over wikidata tags op winkels. maar ID geef dit ook al validatie probleem

voor een oplossing op korte termijn heb ik "not:network:wikidata=Q108742711" toegevoegd aan de super relatie en de twee route relaties toegevoegd.

deze tag instruerend ID dat deze lijnen niet de Vechtdallijnen zijn

osm.org/changeset/140624402

als eerste excuses voor de fout. ID heeft in 90% procent van de gevallen gelijk met de suggesties. maar in dit geval dus niet. het is moeilijk om critics te blijven als het zo vaak goed gaat.

in de history zie ik dat het wel vaker fout gaat. dus ik ben naar de NSI aan het kijken of dat ik het probleem bij de bron kan aanpakken. ik hoop dat de simple fix is dat we wat meer Arriva trein concessies moeten toevoegen aan de data base zodat de matcher niet zo makkelijk hier meer matched.

het problem is waarschijnlijk dat Vechtdallijnen de enige match is met operator=Arriva en dat die dus altijd gekozen word.

ik ga vanavond even kijken ofdat ik wat dingen kan toevoegen aan de NSI.

de lijst is momenteel:
https://wiki.ovinnederland.nl/wiki/Concessie_Achterhoek-Rivierenland
https://wiki.ovinnederland.nl/wiki/Concessie_Limburg_(2017-2031)
https://wiki.ovinnederland.nl/wiki/Concessie_Regionaal_spoorvervoer_Frysl%C3%A2n_en_Groningen_(2021-2035)
https://wiki.ovinnederland.nl/wiki/Concessie_Zuid-Holland_Noord_(2013-2024)

ik hoop dat hiermee het bron probleem is opgelost.

I made an attempt to fix this issue.
osm.org/changeset/140560080

Now that this has been pointed out to me, it feels like a lazy "fix" for the solution.

I hope that the current situation is more to your liking.

It is common practice, when there are translations of tags, in this case "network:en", that there is also a tag with the original language. See also the name tag.

for now, I've created a pull request for the obvious error. for any other discussion, you should write to the folks over at nsi.

https://github.com/osmlab/name-suggestion-index/pull/8568

Hello,

First of all, I am sorry for the mistake.

I've narrowed it down to a mistake in the nsi, which ID uses to suggest tags.

https://github.com/osmlab/name-suggestion-index/blob/af8189f43e1fbda6c57fa41d25405edba604b790/data/transit/route/subway.json#L752

I believe that "Московский метрополитен" could be the correct tag. Can you confirm this for me?

When the fix is implemented, it will take a few weeks for this to get implemented in ID, and till that time, you will get false positives.

- wvdp

I want to thank Dalfsenaartje for all the work he put into the Ada's Hoeve.

And I also want to apologize to him for destroying some of his work.

I truly believe I made the area better and more maintainable.

hallo, ik heb hierbij in de val van de ID editor gelopen.

over het algemeen heeft ID gelijk bij dit soort edits. maar als de dataset van ID nog niet is aangepast dan verander het alles weer terug naar de verkeerde waarde

ik heb een pull request gemaakt op nsi om dit probleem op te lossen.
https://github.com/osmlab/name-suggestion-index/pull/7626

zodra dit ook echt in ID zit kom ik nog een keer langs om mijn rommel op te ruimen

-wvdp

Hello,

My edits are only as good as the research allows them to be.

In this case, I had a source that put the address at 29 and bag, stating that the address was 18t.

In this case, verifying the address on the building is difficult because it is not clearly visible on images online.

The best way to figure out what the address is is to go there in person
So I'm happy that somebody checked the work and found this mistake.

On the topic of addresses on buildings.
I agree that, in general, we don't put addresses on buildings, like with the houses on the other side of the street.

But this is a different case. The whole building is the telecom exchange, so it would make sense to tag the building as such. And then, the telecom exchange has an address that I would like to see on the same object as the telecom exchange.

So, in this case, I find it acceptable to have the address on the building.

On the topic of CGB numbers. They are numbers used to identify the different telecom exchanges. The recommendation to put them under a ref sub-key is accepted.

Then lastly, about not responding. We are all here voluntarily. so I find it inappropriate to request an audience. I get that I'm very late in responding to the first message. But I had less than 24 hours to reply to the second one.

Also, the first message is very constructive, with questions and recommendations. Your message tells me I'm wrong and that we have rules you don't follow. And then, when I don't have time to work on osm for 12 hours, you fix it yourself and demand that I answer for my errors.

Sorry for calling you out like this. I know that you have the best intentions with your messages. I also don't want to discourage you from leaving a message because it is important to discuss the quality of osm. But please also think about the non-verbal message you send with the tone.

I hope that with this message, I've answered all your questions. I'm still open for debate. (although the answers might be somewhat late :) )

-wvdp