Relation and rendering, te weinig gebruikt. Kaartvariatie.

Ik krijg steeds vaker het gevoel dat bij de rendering, relation, te weinig meegenomen word en men veel meer gefocust is op node/way single tag.
landuse gaat dan nog maar…

o.a.
pedestrian

relation highway=pedestrian

Wat ik tevens jammer vindt.
Dat wanneer er geen kaartvoorbeelden zijn, de animo onder taggers afneemt, gaat geen opbouwende motiverende werking van uit.
Moet, zou moeten zijn.
Wat ik doe, wil ik ook zien.
Tag and you get it.

Voorbeelden parking etc.
Meer breedte in free renderings produkten is gewenst.
Nu kijkt men vooral naar die ene kaart, Mapnik.
Nu, wel een paar voorbeelden kaarten/layers, vaak een bepaald gebied, alleen een land.
Niet duidelijk is vaak ook het verversingsbeleid.

Ook ter controle van wat je gedaan hebt. BTM is een mooi voorbeeld.
Meer wereld kaarten gewenst.
World parking layer. for example

Hoe verhogen we de gebruikswaarde van openstreetmap.

Hoe kijken jullie daar tegen aan?

Compliment, ik blijf bij het buitenwerk. Men wil vooral consumeren, in dit geval een kaart.
Ps wat is de betekenis van relation op een way ?

deze map http://www.itoworld.com/map/132 misschien ?

Maar ik geef je gelijk dat er voor bepaalde tags geen kaarten bestaan. Daarom ook dat ik nu met plezier aan “heritage” werk, daarvoor is er wel een kaart. Deze kaart is dan ook nog een in constante ontwikkeling.
En zoals elders in dit forum is aangegeven, een goede kaart voor wandelroutes ontbreekt ook. Een interactieve bedoel ik daarmee. Nu gaat niemand in Vlaanderen de OSM data gebruiken, want wandelknooppunt.be is beter. Hoewel hun data dan weer dikwijls foutief is.

Je bedoelt op het voorbeeld. highway=pedestrian
Vaak een plein of kleine stukjes, te belopen.
Bij een plein heb je binnenin gelegen andere zaken, dus alleen met relation op te lossen.
Je tekent dat niet over elkaar heen, want dan wordt het eronder of erboven gerendeerd, en zie je bepaalde zaken niet. Vanuit Topografisch oogpunt.
Bij kleine stukjes, in de relation eenmaal alle gegevens invoeren, en dan alleen stukjes toevoegen.
Maar wordt het dan wel ergens goed gerendeerd, zie bovenstaand verhaal.
Afweging, hoe taggen.

Die ken ik, maar

Dan waar ik het voorbeeld getagd heb op de ito kaart
Om de gebouwen heen pedestrian in relation is ook niet zichtbaar.

Dat is dus eigenlijk precies wat ik bedoel.
Wat is layerdatum.
Dan nog, hoe gebruik ik die kaartlayer op andere sites.

Wat bedoel je te zeggen met bovenstaande, kun je iets specifieker zijn?

Ik merk dat je geen role gebruikt, volgens http://wiki.openstreetmap.org/wiki/Relation%3Amultipolygon mag dit niet meer. Tools zouden het wel als outer moeten interpreteren, maar ja, dat is dan misschien weer net een stapje te ver.

Ik krijg steeds vaker het gevoel dat bij de rendering van een kaart (basiskaarten en layers), relations, te weinig meegenomen word in de rendering van de kaart/layer en men, als kaart/layer bouwer, veel meer gefocust is alleen op node/way, single, tag.
Als voorbeeld: het stuk stoep bij de parkeerplaats in Wijhe, die niet te zien is op de basiskaart en ook niet op de itokaart, als walkable city.
hier ligt dat stuk stoephttp://overpass-turbo.eu/s/1u3
En zo zijn er meerdere relation tag combinaties.

Dat vindt ik jammer. En mis dus zaken in kaarten/layers…of andere kaarten/layers.

Hoop dat dit specifiek genoeg is.

Je bent duidelijk, dank voor je nadere uitleg. Wat zou de achterliggende gedachte kunnen zijn.

Volgens mij is het gewoon moeilijker om op een efficiënte manier een kaart te renderen als je ook alle relaties in rekening moet brengen. En er zijn ook zoveel tags waarmee je rekening moet houden. En waar vind je ze: op het object of in de relatie, wat bij conflicten tussen die twee.

Een maker van een website die fouten in osm-data opspoort schreef me ooit dat hij geen associatedStreet-relaties wou ondersteunen omdat dat te complex is. Dus al mijn data werd als foutief gemerkt.

Dus in 1 woord: de complexiteit

Aangepast, role outer.

dat zal het zijn complexiteit.

of houden de andere meer specialistisch kaartenbouwers dat voor zich.