Voorstel voor taggen dubbele landuse

Ik kwam laatst de situatie tegen in het winkelgedeelte van een stadscentrum dat ik twijfelde of ik landuse=retail of residential moest gebruiken. De winkels zitten op de begane grond en apartementen daarboven. Uiteindelijk heb ik retail gepakt maar ik bedacht me dat het handig kan zijn om meerdere landuse gebruiken aan te geven. Dat is iets wat vaak voorkomt, zeker in steden, en nu kiezen we er vaak een maar landuse=retail bijvoorbeeld geeft niet aan dat er woningen boven zitten. Je kunt wel residential=apartments gebruiken maar dat is eigenlijk een subtag voor landuse=residential die ik eigenlijk niet wil gebruiken om aan te geven of er woningen boven de winkels in een retail gebied zitten.

Ik heb eens idee uitgetypte [1] en ik vroeg me af of er interesse is in een dergelijke oplossing (kan ook best een andere tag dan de voorgestelde zijn. Het gaat om het idee). Het hoeft niet anders te renderen (voor alsnog in het begin in ieder geval) maar de extra informatie kan wel nuttig voor datagebruikers zijn die de landuse informatie gebruiken. Het gaat me er om dat de huidige landuse tags zeker in steden te kort schieten om goed het landgebruik aan te geven zonder dat je vlakken over elkaar heen moet tekenen.

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Multiple_landuse

Dat is inderdaad wel een lastige. De gangbare wijsheid is dat er altijd een primaire landuse is, dus een aanvullende tag kan dan handig zijn. Die situatie van winkels (primair gebruik) met bewoning erboven is iets wat we in Nederland natuurlijk veel hebben.

Is het nummeren wel nodig? Ik kan me voorstellen dat je met landuse:additional=residential;commercial (bijvoorbeeld) ook bent. Dat scheelt weer complexiteit.

Overigens niet alleen in NL en niet alleen voor winkels/woningen.

Dat kan ook hoor. Ik dacht splits het op zodat de tags los staan. Maakt het wat makkelijker te gebruiken omdat je ze dan niet eerst hoeft te splitsen. Maar goed, de eerste landuse via landuse=* die moet wel los want daar wordt op gerenderd.

Dat is voor geautomatiseerd gebruik geen bezwaar. Het is juist makkelijker als de tag-naam bekend is. Ik schat dat je in 95% van de gevallen ook aan één waarde genoeg hebt (en dat is dan natuurlijk 95% van de misschien 5% van de gevallen waar er sprake is van dubbel landuse).

Heb je eigenlijk al eens een voorbeeld gevonden van meer dan twee landuses? Ik ben wel benieuwd waar je zoiets vindt.

Op Discord gaf iemand dit voorbeeeld: “There’s a school downtown in Toronto which is institutional, has retail shops, and apartments above the classes”. Als het een groot pand is met alle gebruik over hele verdiepingen dan kun je niet stukjes landuse tekenen. Dan omvat ieder landuse et hele gebouw. In het voorstel staat trouwens ook De Rotterdam. Dit is een toren met meerder gebruik. Ik heb er in het voorbeeld commercial en residential van gemaakt maar misschien dat retail ook nog van toepassing is.

Ik denk dat 2 landuse ook de meest voorkomende is inderdaad. Op discord gaven ze al aan niet zo’n fan te zijn van dat nummer systeem. Daar vinden ze de :additional=* helemaal niets en willen ze liever residential=, retail= etc maar dat zijn subtags met een ander doel, lijkt me niet goed voor dit.

Landuse impliceert dat je dit tagt overeenkomstig met wat de eerste bouwlaag voor gebruiksfunctie heeft.

Dat doet geen enkel recht aan wat de dominante functie is van een bepaald landoppervlak als zich bij een flatgebouw boven een onbeduidende retailfunctie 15 woonlagen zijn.

Voor de oplossing wordt teveel gefocussed op landuse terwijl er andere meer pragmatische contextgebaseerde oplossingen zijn waarvan ik erken dat sommige tegen 3D-mapping aanschuren

(Alle voorbeelden gaan uit van woonlagen boven retail)

  • Als alle winkels met klein verzorgingsgebied op de begane grond van een woonflat individueel een shop tag hebben (met pictogrammen) dan landuse=residential
  • Als er geen individuele shops met klein verzorgingsgebied getagged zijn dan wordt landuse bepaald op basis van verhouding woondichtheid en mate aanwezigheid essentiele winkels (bij bloemist / kapper residential en bij buurtsuper retail)
  • Gearceerd renderen van mixed landuse
  • Is het verzorgingsgebied groter dan de wijk zelf dan vanzelfsprekend landuse=retail
  • Renderkleur van gebouwen afhankelijk maken van tagging (Woontoren op landuse=retail) met renderkleur die halfwaarde is van standaard building (bruin-grijs) en overeenkomende landuse
  • Renderkleur gebouwen is ook bruikbaar omdat de voet van bebouwing vaak groter oppervlak heeft dan bovenliggende bouwlagen (2D renderingrules voor 3D-mapping)

Bedankt voor het meedenken. De reden waarom ik nu aan een landuse oplossing denk is dat landuse vertaald landgebruik is. We geven wel aan dat de hoofdfunctie bijvoorbeeld retail is maar het land wordt daarnaast ook nog voor bijvoorbeeld residential of commercial gebruikt. Naar mijns inzien nog steeds landgebruik.

Daarnaast, het gaat met niet alleen om het renderen want OSM is een data project, niet alleen een kaartproject. Hiermee verbeter je de kwaliteit van de data. Met landuse=* geef je de hoofdfunctie aan en met landuse:additional=* geef je zeg maar nevengebruik aan.

Maar goed, ik had er inderdaad ook over nagedacht om de invulling van een landuse mee te nemen bij het bepalen van het gemengde landgebruik. Als er echter building=retail of building=yes op een pand staat dan zegt dat nog niet veel. Je zou dan wel kunnen zeggen, alleen adresnodes zonder winkelfunctie zijn woningen. Klopt niet helemaal omdat niet alle winkels zijn getagd maar kan op zich wel al. Ik vraag je alleen even af of bijvoorbeeld een carto dat technisch ook kan en dat er dus gevarieerd kan worden op rendering.

Dan moeten die analyzes wel iedere keer worden uitgevoerd om het dual landgebruik te bepalen.

Is het niet veel eenvoudiger om er een multipolygoon van te maken ?
Landuse=Retail om het flatgebouw opnemen als inner en landuse=residential als outer.

Natuurlijk heeft dat als nadeel dat de bovenliggende woningen in het Retail blijven staan, maar die worden dan wel weer omvat door de outer.

En bedenk wel: hoe ingewikkelder de tagging wordt, des te minder mappers zullen het toepassen.
Dat eindigt dan dat je in je eentje heel NL zou moeten doen. :expressionless:

Multipolygon en andere vormen van “relation” zijn nooit eenvoudig. En zouden hier niets toevoegen behalve complexiteit. Zoals ik het begrijp was het data-type “relation” ook nooit bedoeld voor dit soort toepassing.

Meestal ligt de landuse=retail al over een landuse=residential.
Maar los daarvan:
landuse=retail
building=apartments
(Het gebied is voor de meeste bezoekers een winkelbestemming, de gebouwen bestaan voornamelijk uit woonlagen)

landuse:additional=…;…;… is toch niet al te lastig?

Dat over elkaar heen tekenen is niet echt een mooie oplossing. Wat nu als de residential en retail vlakken precies op elkaar liggen?

Daarnaast, building=apartments aan een pand koppelen wat ook als winkel wordt gebruikt klopt dan ook niet.

Het gaat me er om dat in het huidige systeem, de mapper de meest dominante landuse moet kiezen en dat alle andere vormen van landgebruik of niet getagd worden of er overheen wordt getekend. Die informatie wordt dus nu achterwege gelaten of lelijk ingetekend. Dit is voor zowel renders en data gebruikers niet handig.

Lijkt me behoorlijk minimaal en optioneel bovendien. Zeker niet lastig.

Het is ook niet wenselijk vanuit de opzet dat er één primaire landuse is.

Nee klopt maar op deze manier kan landuse=* blijven zoals ie is. Anders verander ik een heel systeem. Dan moeten renderers ook aanpassen. Het kan, maar dat maakt het proposal process ook lastiger

Oh dat bedoel ik niet als kritiek; wat je voorstelt klopt juist met dat uitgangspunt. Een primaire landuse die vanuit de conventie in landuse staat met de aanvullende landuses in de aparte tag.

Ah mooi, dan had ik het verkeerd begrepen.

Het proposal is trouwens aangepast naar landuse:additional=example;…;… Ook op Discord waren ze geen fan van dat nummer.

Hi Cartographer10, how or what kind of medium is Discord and how is it related to OSM ? IMHO there are already to many media concerning about OSM, you cant read them all and go out and survey to make OSM a better map / database.

Discord is een communicatieplatform. Daar is het OSM world Discord kanaal. Daar komen veel internationale mappers samen. Daar is een apart proposal kanaal waar ik mijn eerste ideeën heb besproken.

https://discord.gg/openstreetmap

Je kan overwegen om in het voorstel te definiëren dat de meerdere waarden van de nieuwe tag op aflopende volgorde van belangrijkheid staan. De hoofd-landuse-tag is immers al de primaire, dus dan is het handig om nu alvast vast te leggen dat de volgorde van landuse:additional daarop volgt (dus dat de eerste waarde van landuse:additional de secundaire landuse is, en de volgende de tertiaire etc.).

Omdat het toch al uitzonderlijk is dat er meer dan twee zijn zal dat weinig problemen opleveren met taggen, maar het is wel handig voor data consumers. Ook zou een renderer die gemixte landuse wil tonen er voor kunnen kiezen om zich te beperken tot twee (vanwege designredenen); die kan er dan veilig van uitgaan dat bij “landuse:additional=residential; commercial” de eerste (residential) de secundaire is (bijvoorbeeld samen met landuse=retail).

Imagico stelt ook al zoiets voor op de talk page. Hij gaat zelfs verder en zegt, kies landuse:secondary, landuse:tertiary etc. Dan impliceerd de naamgeving ook al een soort rang. Dit systeem had ik ook in eerste instantie maar voor het proposal heb ik het toen naar landuse:additional veranderd. Dit maakt het voor data gebruikers makkelijker om de data te gebruiken omdat de waardes los staan.

Maar lijkt me prima om een rang aan te geven. Je hebt gelijk dat landuse de primaire is. Het is dan wel de vraag in hoeverre de rang voor een mapper verifieerbaar is

Als de mapper het niet zeker weet is het prima ze in de volgorde die die redelijk lijkt te zetten. De mapper moet immers ook inschatten wat de primary landuse is. Meer dan twee landuses waarbij je ook niet kan inschatten in wat voor orde van grootte dat is zijn denk ik zo uitzonderlijk dat je daar niet veel problemen mee creëert. Één enkele landuse:additional tag is wel mooi overzichtelijk, en je had ook al ingeschat dat meer dan twee landuses uitzonderingen zijn.