Beste Ad,

In deze changeset heb je o.a. een artillerie vuurzone voor de kust van Noord Holland ingetekend. Nu lijkt deze zeer grof ingetekend, hij valt zelfs gedeeltelijk over de kust en het nucleaire onderzoekscentrum NRG... Dat kan toch niet kloppen.

Ik kan uit de door jou opgegeven bron, ook niet een dergelijk gebied extraheren. Op pagina 53 van het gelinkte document, staan 2 individuele "taartpunt"-achtige artilleriezones, die geen relatie met het door jouw ingetekende gebied lijken te hebben, anders dan "voor de kust van Noord Holland".

Mogen wij deze bron trouwens gebruiken? Zo ja, dan toch beter om het nauwkeuriger over te nemen. Nu suggereert het dat de reactor van Petten een potentieel vuurdoel is..., terwijl uit de tekst van het document blijkt dat er vanuit twee batterijen richting zee wordt geschoten (gebieden 3 en 4 in kaart van pag. 53).

Mvg,

Marco

Yes, no problem ;-), I agree its a minor issue and I understand your reasoning, and I think it is fine like this. There will always be some issues with the translation of the real world to the secondary fictional world of a map and its data model. We don't want to map 1:1 as the famous stories go... https://en.wikipedia.org/wiki/On_Exactitude_in_Science

No, this was certainly not some semi-automated edit. I carefully selected and reviewed all of the features in the changeset. Most were obvious issues. As to the particular issue with court yards, as you write, it is not building=yes, and thus needs exclusion. Everybody will reasonably understand it is likely part of the complex's ownership, even if not included with the specific building tagging, so I don't think this is an issue at all.

Dank, probeer het altijd netter achter te laten dan ik het aantref. Kennelijk gelukt!

Martin: het zijn niet dezelfde oppervlaktes. De outer is een duidelijk andere shape / vlak dan de MP. De MP met landuse=grass is qua oppervlak kleiner, en ligt feitelijk binnen de landuse=Industrial.

Daarnaast is het zo, dat hoewel wij in OSM gras als landuse zien, dit feitelijk meer een landcover is. Industrial vormt meer een administratieve grens. Landuse=grass kan daarmee binnen een groter vlak van landuse=Industrial liggen.

Feitelijk is er een hierarchy van landuses:
- landuse=industrial/urban/railway/commericial zijn de grootschalige urbane cq. bebouwde landuses. Deze sluiten elkaar onderling bijna altijd wederzijds uit, en sluiten op elkaar aan.
- Daarnaast heb je vaak kleinschaliger een "tweede laag" van landuse (eigenlijk landcover): landuse=grass/forest/etc.
- Soms is er nog een derde laag. B.v. leisure=park/garden/playground etc.

En "muujte" hierboven moet natuurlijk "muurtje" zijn ;-) Helaas geen edit optie bij opmerkingen. Het is te laat, ga nu slapen.

Feitelijk is de fence ook weer een apart object, het is namelijk een lijnobject, en kan heel goed onderbroken zijn door b.v. een muutje, heg of een sloot. Best vaak loopt het niet helemaal rond. Ik tag ze soms echt apart, en laat dan b.v. een kleine opening bij de ingang tot het terrein.

Wylre: mijn fout ;-) (kwam het ergens op een website tegen). Is inmiddels gecorrigeerd.

En om bij de Wiki terug te komen:

"Tags describing the multipolygon (e.g., landuse=forest) always go on the relation."

-- > Dit is dus de "landuse=grass" tag van je achtertuin! Dat is namelijk de tag die de multipolygoon beschrijft!

"The outer way(s) must be left untagged[1], unless they describe something in their own right."

-- > Het "unless they describe something in their own right." slaat dus op de perceelgegevens.

De naam van de RWZI, het adres, en de contactgegevens zijn dat "something in their own right" en moeten juist op de outer. Hetzelfde als het gaat om je achtertuin: de perceelsgrens is een object op zich, en daaraan hangen jouw eigendomsgegevens. Nogmaals: die vijver hoort toch ook bij jouw tuin?

Martin, het gaat er niet om of ik of de Wiki gelijk heeft, ik onderschrijf de Wiki volledig.

Maar het probleem is dat je kennelijk nog niet helemaal door hebt hoe MPs werken, en waarvoor ze bedoeld zijn.

Beantwoord nogmaals de volgende vragen:

- Behoort het vijvertje in jouw achtertuin tot jouw tuin? Valt het binnen de perceelsgrenzen. Zo ja, dan wordt het grasveld een MP, en jouw eigendom vastgelegd op de outer. Is de vijver van de gemeente, dan wordt jouw perceelseigendom WEL een MP met de vijver als inner!

- Behoort de leisure=swimming_pool in het grasveld tot het terrein van het zwembad? Zo ja, dan wordt het grasveld een MP, en het hek om het hele zwembad, die de outer vormt, getagged met de zwembad gegevens (naam, telefoon, adres etc.)

Nee, dit is echt een foute gedachte... Een MP is niet een type=site relation die willekeurige objecten bij elkaar voegt onder een relatie!

Een MP is puur bedoeld om gaten te slaan in een groter vlak (donut shapes), en het daarmee mogelijk te maken om geometrisch aansluitende objecten, i.p.v. overlappende te maken. Dus b.v. een vijver in een grasveld van een tuin is een MP, de perceelsgegevens (eigenaar), zouden juist op de outer moeten.

Ik denk althans dat je het mij eens zult zijn dat als ik jouw vraag: "Behoort dat vijvertje in je achtertuin bij jouw tuin?", dat je dan volmondig "Ja" beantwoord. Maak je er een MP van, dan zeg je feitelijk "Nee".

Overigens ligt het bij gebouwen natuurlijk anders, daar moeten juist WEL de gegevens op de MP, want het binnenpleintje is natuurlijk NIET een gebouw / hoort niet bij het gebouw.

Resumerend, je moet MPs niet gebruiken om zaken die in jouw ogen bij elkaar horen, administratief te verbinden, daarvoor heb je eventueel de type=site relation.

Ik neem het je overigens in het geheel niet kwalijk, want dit is een door velen gemaakte denkfout.

Martin: het specifieke probleem hier (en bij meerdere andere RWZI's / kampeerterreinen en golfterreinen die in de omgeving van deze in Limburg heb gecorrigeerd) is nu juist dat de MP helemaal niet de buitengrens van de RWZI (zeg maar het hek eromheen) voorstelt. De MP representeerde namelijk het gras uit waarschijnlijk 3dShapes... oude import meuk dus.

Dit was dus juist eerst fout getagged. In deze specifieke gevallen moet je dus juist het tegenovergestelde doen van de "conventie": namelijk de outline taggen met de RWZI gegevens, niet de MP, en de MP re-taggen tot wat het werkelijk is, b.v. landuse=grass of forest.

Anders zouden dus bijvoorbeeld de waterbassins volgens de MP niet tot het terrein van de RWZI behoren, want ze zouden buiten de MP vallen als inners. Dat is te zot...

Het probleem is een beetje, dat veel mensen bij het taggen van b.v. een RWZI of golf terrein, maar gemakshalve het eerst grote object pakken dat grofweg de outline van het object voorsteld en dat gaan taggen. Als dat toevallig een MP is met een heleboel inners die eigenlijk bij het terrein van de RWZI / golfclub / kampeerterrein horen, dan is dat een nogal ongelukkige keuze. Dit gebeurd helaas vaak.

Beste Jimiee,
Er zijn verschillende redenen waarom de oude tagging niet klopte:
- Individuele kamers in een gebouw zijn niet zelf een gebouw (building=x). In Nederland is - in een door de meeste Nederlandse mappers geaccepteerde stilzwijgende overeenkomst - de BAG de belangrijkste leidraad voor de gebouwen in OSM, en daar staan geen individuele ruimtes van gebouwen in.
- Door de ruimtes wel foutief als gebouw te taggen, duw je alle andere renderaars / gebruikers van de data en kartografen deze features zogezegd "door de strot". Ze kunnen deze namelijk niet meer onderscheiden van wat daadwerkelijk gebouwcontouren zijn... Door in plaats daarvan het Indoor tagging scheme te gebruiken, kan men wel naar eigen wens de features wel of niet tonen, in plaats van ze gedwongen te moeten consumeren.
- De standaard rendering is niet bedoeld om indoor features te laten zien. Daarvoor kun je veel beter een specialistische tool als OpenLevelUp gebruiken (https://openlevelup.net). Die heeft bovendien het grote voordeel dat je de verschillende levels binnen een gebouw kunt tonen. Als je nu in OpenLevelUp kijkt, zul je zien dat het gebouw mooi te bekijken is met zijn indoor features, want ik heb de ontbrekende level tags toegevoegd (en de foutieve layer=x verwijderd). Tip voor gebruik OpenLevelUp: zoom eerst in op het winkelcentrum, klik dan op de blauwe level bar rechts op "2" om de indoor features zichtbaar te maken van het winkelcentrum. Zoek trouwens ook eens b.v. het Louvre museum op in Parijs, dan zie je snel wat het voordeel van de individuele levelweergave in OpenLevelUp is. Het zou onmogelijk zijn om dit in de standaard rendering weer te geven!

As I wrote before, I am actually still surprised the original multipolygon relation rendered at all in the Standard layer...

Yes, I know, but ultimately, if you do want the data to display in the "Standard" style, you will unavoidably need to consider this to some extent: osm2pgsql fills the PostGIS render database of openstreetmap-carto, and that database essentially needs Simple Features, as that is what PostGIS is based on AFAIK. If I understood it well, there were/are some hacks going on behind the scene to allow the generation of more valid polygons, but that is something to keep in mind. If there is the possibility to generate a multipolygon relation that is also Simple Features compliant, then I think that is the prefered option.

Hi Andy, the Clipstone forest multipolygon had one inner that touched the outer over a considerable length. This is technically not allowed (and certainly not in international Simple Features GIS standard), and I am actually surprised it rendered at all and PostGIS / osm2pgsql managed to create something apparently valid from it. The error was at the position of what I have now tagged as a landuse=meadow, where the Sherwood Pines Cafe is located. I have changed this by making the outer go around the meadow, which also seemed more appropriate, as it isn't really forest (although administratively it might be, still, this is an unsolvable issue unless we come up with a proper administrative boundary type for things like forests).

Even los van het feit dat het misschien best nuttig is voor de Duitse toerist om de ook de Duitse dieren namen in de database te hebben en misschien ergens gerenderd te zien, denk ik toch dat je even verder zult moeten zoeken naar wie het heeft toegevoegd als je erop wilt reageren. Zoals je al aan de changeset comment van mijzelf kunt zien, heb ik in deze changeset helemaal niets met namen gedaan.
Bedenk verder wel dat OSM een wereldwijde database is. Internationale namen op b.v. plaatsen / steden toegevoegd door buitenlanders / natives, zou ik zeker nooit verwijderen. We zijn niet alleen met onze eigen postzegel op deze aardbol bezig in OSM...

Hi,

I noticed that near Aydius, you have added a number of features with the man_made=water_tower tag. Looking at the Bing imagery, it is difficult to ascertain, but it seems many of these features are really small, and don't constitute what is generally considered a water tower connected to some public utility water network, which is what the man_made=water_tower tag is most used for.

Also, a number of features carry the name "impluvium", which again suggest that these are not water towers. In case of a small open air reservoir, as the "impluvium" suggests, it might be more appropriate to add "landuse=reservoir", despite the small size. Alternatively, if covered, "man_made=reservoir_covered" can be used for water reservoirs.

Lastly, if these are just small private water tanks, than "man_made=storage_tank" with "content=water" would be a valid option for tagging and more appropriate than man_made=water_tower.

Basically agree based on the imagery I see of the area and the mapping, and if the whole area is already covered by a park tag. Maybe it would be better to remove this particular way feature, and just leave the meadows tagged with the disc-golf names, but that is up to a local mapper.

Alternative is a new leisure=disc_golf_course tag I see listed in the Wiki:
osm.wiki/Tag:leisure%3Ddisc_golf_course

Hi Daniele,
Congratulazioni!
I have now made the suggested changes. I set the part to tertiary, and used JOSM to remove those sections of road not officially belonging to SP7. I also removed some name and ref tags on these sections that also referred to SP7.

Daniele,

One last remark: shouldn't it be a "tertiary" road as well, as the remaining part of the SP7 is currently tagged?

Or is it maybe better to classify the road entirely as "secondary", also the remaining part futher into to the valley?

Of course, this is dead end, I don't know what the italian community uses to classify such roads not connecting to any further network, so maybe tertiary is indeed the best tag.

Marco