Viajero, OK, yes I see this was already discussed.

However, while I can understand a scheme based on tertiary and unclassified, most of the roads tagged here are secondary and tertiary, even the dead end roads leading to nowhere (no buildings / caravans / huts visible in the detailed imagery available), so I do think these would need to be downgraded. Maybe its ongoing work, because I see some similar tracks as unclassified as well.

All in all, I think I lean more to Andrew_Finn's tagging suggestions in the link you provided (https://forum.openstreetmap.org/viewtopic.php?pid=702664#p702664), where track is still a significant tag for most of these roads.

I do also wonder why especially tracktype=x tagging has not been more universally adopted by the Canadian community (osm.wiki/Key:tracktype). This baffles me. Especially in a country with so many unpaved roads and tracks that may serve functions beyond forestry access, adding tracktype to all unpaved roads/tracks would seem logical to give better information about the solidity and quality of the road from a driving perspective.

Hi Robert,

I noticed you added a lot forestry tracks west of Port Alberni with a road classification that seems disputable, like highway=secondary/tertiary.

This is undesirable. Even if they are build to high standard for resource extraction with heavy equipment, a track remains a track if it doesn't serve the purposes and functions as documented in the OSM wike for a highway=secondary/tertiary, that is, secondary roads and tertiary roads are supposed to connect population centres. Dead end forestry tracks, even when build to a standard that might function as a highway=secondary/tertiary in developing countries where they DO connect population centres, should still be tagged as tracks.
I am actually slightly suprised you added it like this, as I saw you confirming a more sensible tagging scheme by Jack the Ripper (osm.org/user/Jack%20the%20Ripper/diary/41953), that does conform to the more generally accepted road classification standards in OSM and their usage, yet you haven't implemented it here.
Adding extra notes in tags like "comments" or classifying the roads as "service=resource extraction" isn't helpful. What are data consumers supposed to do? Convert all roads tagged with "service=resource extraction" to tracks? This would be really undesirable, just imagine everybody started tagging roads as highway=secondary/tertiary and adding (multiple) secondary imaginary tags just to say: "Sorry, this isn't actually a true secondary/tertiary road, I just tagged it like that for my own purposes, and now you have to deal with it"

Marco

Hendrikklaas, je hebt hier een power=plant aangegeven zonder enige details, wat op de luchtfoto's nog gewoon weilanden zijn. Wat ligt hier nu echt? Het zou helpen als je details aangeeft, zoals de naam van de "plant" en de operator. Is dit b.v. een installatie op zonne-energie of zo? Zo ja, dan is b.v. operator=x, plant:source=solar, plant:method=photovoltaic en plant:output:electricity=x nuttige tagging.

Well, if that was the case, then I am sorry, because I certainly had no intention to move anything, but only wanted to retag the objects.

How do I interpret the OSMCha data though, I have little experience with the tool. Looking at some of the points, it appears a bunch of them somehow ended up on a kind "lined-up" configuration at the bottom of the edited extent??? I have no idea how that would have happened, other than some weird issue I didn't notice in JOSM, or some unintended move of selected nodes.

Anyway, I noticed you reverted the coordinate change, so thanks for fixing if they are now in the correct place again.

Hi dikkeknodel,

Thanks for the detailed reply that explains more about the situation and background of these edits. I am fine if you revert this and enrich the data using the wildcamp tagging.

Cheers, Marco

Hi dikkeknodel,

A couple of thoughts here:
- The tagging of camp sites is still mildly in flux. I can't remember having seen a "camp_type=wildcamp" on the pages when I last checked them, sometime before this edit, but it now seems documented. At the time of this edit by me, with no known established tagging for marking out wildcamps, the best course of action seemed to remove them.
- I do think that tagging wildcamps without any sign, nor even note, that they are wildcamps, is kind of lazy and potentially dangerous. People may expect services (e.g. drinking water) that are not available. This is also a bit worrying coming from someone who actually must be an experienced hiker / climber to even know about, and have used, such a place to start tagging it on OSM. A regular ignorant tourist would not know about such a place at all.
- Also in this respect, while I understand the use of a subtag like "camp_type=x" is logical and much used in OSM, I do have some doubt in the case of wildcamps. Wildcamps are so totally different from any regular 'established/informal' camp site, that a separate tag might have been a better choice, e.g. tourism=wildcamp.
- This is especially so because any website / rendering not knowing about or checking the subtag "camp_type=x", may inadvertently show this on a map targeted at regular tourists without any climbing / hiking experience. This could lead to unpleasant situations and at the very least confusion.

Anyway, it is OSM, so if you want to revert this,you can do it. But as you suggested, I would definetely tag them as "camp_type=wildcamp". Lastly, it might be good to have the actual locations double-checked locally before reverting this. I am definitely not in a position to do that, but don't know your location, or if you have contacts with local mappers and hikers that know the locations and paths leading to them. I do have some doubts about re-adding these without a double check if the locations are actually sound.

Ok, dank voor de reacties. Dit verduidelijkt een hoop. Ik snap nu beter hoe dit gebied tot stand is gekomen, en dat het in ieder geval niet een onnauwkeurige grove intekening is, maar gebaseerd op daadwerkelijke coördinaten gegevens.

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...