Provincie van de Maand - Zeeland

Lachgast · 2024-11-05T08:53:40.116Z

emvee · 2024-11-06T06:36:39.536Z

Ik was wat afgeleid door campings/parken (o.a. deze changeset en zie hieronder) maar nu wil ik toch maxspeed voor Zeeland gaan aanpakken.

Zeeland_begin_maand993×846 108 KB

Qua aantallen valt het mee:

motorway :: missing maxspeed: 0, total: 470, pct with maxspeed: 100.0
trunk :: missing maxspeed: 12, total: 834, pct with maxspeed: 98.6
primary :: missing maxspeed: 24, total: 1955, pct with maxspeed: 98.8
secondary :: missing maxspeed: 72, total: 2843, pct with maxspeed: 97.5
tertiary :: missing maxspeed: 164, total: 4107, pct with maxspeed: 96.0
unclassified :: missing maxspeed: 2014, total: 10087, pct with maxspeed: 80.0
residential :: missing maxspeed: 3006, total: 14074, pct with maxspeed: 78.6
living_street :: missing maxspeed: 11, total: 450, pct with maxspeed: 97.6
total :: missing maxspeed: 5303, total: 34820, pct with maxspeed: 84.8

emvee · 2024-11-06T06:47:16.289Z

Wat betreft campings/(vakantie)parken, wat naar mijn idee nodig is dat varianten die nu nog als node gemapt zijn als gebied worden gemapt.

Waarom?

Zo kan je bijv. kleine campings vinden
Als je de camping/het park als gebied hebt en de wegen in het gebied kan je een analyse maken hoe goed alles bereikbaar is.

Van de 427 campings in Zeeland is maar 15% als node gemapt, de andere 385 als way/relation.

Ik wil me focussen op maxspeed, maar mochten er mappers zijn die nodes willen omzetten voor Zeeland:

maproulette.org

MapRoulette

Be an instant contributor to the world’s maps.

Als je een node om zet, kijk dan gelijk even naar het wegennetwerk op de camping/het park.

erik1984 · 2024-11-08T22:26:18.336Z

Heb er eentje bijgewerkt als test: Way: ‪VierVaart‬ (‪1332075387‬) | OpenStreetMap

Zit wel nog steeds met dupliceren van adres in mijn maag maar heb nu maar ervoor gekozen om dat wél te doen aangezien de oorspronkelijke campingnode ook het adres had (andere BAG-node).

erik1984 · 2024-11-09T11:06:38.013Z

Nog een (zelfde situatie met adres): Way: ‪De Brashoeve‬ (‪1332168442‬) | OpenStreetMap

emvee · 2024-11-09T11:27:54.133Z

erik1984:

Zit wel nog steeds met dupliceren van adres in mijn maag maar heb nu maar ervoor gekozen om dat wél te doen aangezien de oorspronkelijke campingnode ook het adres had (andere BAG-node).

Bekend probleem. Wat mij betreft is een dubbel adres in dit geval goed en geen probleem, zelf kies ik er vaak voor om de camping area maar geen adres te geven.

erik1984 · 2024-11-09T12:10:57.518Z

Qua wegennetwerk, zou het meerwaarde hebben om op de veldjes met kampeerplaatsen paden in te tekenen? Voor de laatste camping die ik via MapRoulette heb aangepast stonden de verharde wegen wel (deels) op OSM maar op de velden niet. De vraag is of hier überhaupt wel paden zijn. Ze zijn niet heel duidelijk als losstaand pad zichtbaar op de luchtfoto in elk geval. Dus intekenen daarvan is mogelijk strijdig met “Map what’s on the ground”?

afbeelding862×613 99.9 KB

OpenStreetMap

Way: ‪De Zwinhoeve‬ (‪1332176191‬)

OpenStreetMap is a map of the world, created by people like you and free to use under an open license.

Roelieboelie · 2024-11-09T13:02:36.326Z

Misschien de eerste paar meters highway=track intekenen. Dan Is iniedergeval duidelijk via welke kant je het grasveldje in kan.

emvee · 2024-11-09T14:30:07.333Z

Wat betreft tracks intekenen met @Roelieboelie eens.

Wat je ook nog zou kunnen mee nemen als criteria is afstand als een ding van de camping/het park verder dan ~100 meter ligt van een bestaande weg dan ook tracks intekenen als die er zijn.

erik1984 · 2024-11-09T19:52:32.017Z

Check! Bij deze camping heb ik het verbeteren van de paden proberen toe te passen: Node: ‪Wulpen‬ (‪2827660226‬) | OpenStreetMap Hierdoor niet meer toegekomen aan wat ik daar eigenlijk wilde doen (de parkomtrek aangeven voor MapRoulette…)

erik1984 · 2024-11-13T21:34:31.182Z

Dit park is wel een leuke hersenkraker voor het goed mappen van campings / vakantieparken:

maproulette.org

MapRoulette

Be an instant contributor to the world’s maps.

Hier ben ik toch wel een tijdje mee aan het puzzelen geweest maar had al zoveel geprutst dat ik uiteindelijk geen changeset meer heb gemaakt. Eigenlijk heeft het park juist een handige site met luchtbeelden en een mooie plattegrond. Van links naar rechts heb je eerst een gedeelte met huisjes dat eigenlijk een eigen park vormt. Dan een stuk camping om het hoofdgebouw heen en na de camping weer een stuk met huisjes. Hoe kan dit als geheel fatsoenlijk op de kaart worden gezet?

Allroads · 2024-11-13T23:05:24.682Z

erik1984:

… mee aan het puzzelen geweest …

kaart van deze site die komt bij deze website welgelegen vandaan.
twee parken?

emvee · 2024-11-14T07:45:36.849Z

Het probleem is volgens mij: Is het een camping of een vakantiepark?

Vakantiepark: tourism=chalet_site? Nederland (Netherlands)

N.a.v. deze changeset rijst de vraag hoe het beste een vakantiepark met vaste huisjes kan worden getagd. We kennen: tourism=camping_site tourism=caravan_site maar dit: tourism=chalet_site bestaat nog niet maar zou er wel het beste bij passen. Op dit moment zie je bij taginfo de oplossing: tourism=chalet;caravan_site D.w.z. een dubbele waarde, iets waar de standaardrendering nog geen raad mee weet. Heeft iemand een andere suggestie voor een vakantiepark?

Je zou dus de omtrek kunnen mappen met leisure=resort en dan delen tourism=camp_site en tourism=chalet.

leisure=resort lijkt me in dit geval minder goed te passen omdat het park geen “entertainment features” heeft zo te zien maar dat zou ik niet al te strict nemen.

Je zou ook de delen camp_site en chalet samen nemen in een relation van het type site met de omtrek als perimeter.

Campings met slechts enkele chalets kan je beter mappen met tourism=camp_site + cabins=yes

erik1984 · 2024-11-14T20:27:51.274Z

type=site kende ik nog niet, dat is zeker interessant.

Maar hoe dan ook vraag ik me af hoe we dit voor dataconsumenten geschikt kunnen aanbieden. Van site=camp_site zie ik in Nederland 1 voorbeeld en dat lijkt me onnodig gebruik gezien de area (waar weer tourism=camp_site op staat) alle info al bevat: Relation: ‪Uit den Haak‬ (‪1125754‬) | OpenStreetMap.

Dit park lijkt me toch primair een bungalowpark (dat staat in het logo) dus dan zou het site=chalet kunnen worden.

Anyway, dit is een schot voor de boeg met site: Relation: ‪Park Welgelegen‬ (‪18287812‬) | OpenStreetMap … misschien dat de oude situatie met een losse campingnode beter was. In elk geval veeel eenvoudiger.

emvee · 2024-11-14T21:14:21.937Z

Het blijft aanschipperen met dit soort combinaties maar het ziet er wat mij betreft niet slecht uit.

Ik zou nog twee dingen aanpassen om de data beter bruikbaar te maken voor dataconsumenten:

Geen site=chalet (dat wordt niet herkent) op de relatie maar tourism=chalet.
De camp_site van name en website voorzien, zodat iemand die zoekt op campings in ieder geval de naam en de website krijgt.

erik1984 · 2024-11-14T21:34:01.815Z

Check! Al lijkt nominatim er nu nog steeds niet veel mee te kunnen als het op een site staat. Park Welgelegen komt niet terug als tourism=chalet, wel als tourism=camp_site nu.

emvee · 2024-11-14T21:48:20.843Z

erik1984:

Al lijkt nominatim er nu nog steeds niet veel mee te kunnen als het op een site staat.

Dat is inderdaad opmerkelijk, als je op “Schoolzicht” zoekt dan vindt je wel een tourism=chalet relation maar die is van het type type=multipolygon dus het lijkt inderdaad met type=site te maken te hebben…

erik1984 · 2024-11-14T21:58:14.531Z

Omdat ik site niet kende was ik daar aanvankelijk ook mee begonnen maar dan mag je de gebieden niet aan elkaar plakken. Tenminste de validator in JOSM vindt dat niet leuk. Wat zou kunnen is een multipoly maar dan kunstmatig wat marge tussen de gebieden open laten?

emvee · 2024-11-14T22:26:59.507Z

Net zo als “taggen voor de renderer” ben ik niet z’n voorstander van “taggen voor nominatim”

Ik voel er wel iets voor om dit bij nominatim aan te kaarten, ik heb inmiddels gezien dat het niet beperkt is tot tourism=chalet/camp_site. Even zoeken levert op:

github.com/osm-search/Nominatim

Relations of type=site won't be found by Nominatim

opened 05:09PM - 08 Jun 16 UTC

ngt-github

enhancement Indexing

A Relation type=site is not found by nominatim. There a few thousand relations o…f this type and some are holding addr:\* tags. Nominatim should find those addresses! JOSM even has a template preset and therefor this relation type is used. [OSM Wiki Relation:site](http://wiki.openstreetmap.org/wiki/Relation:site) [Nominatimquery for an address using type=site](http://nominatim.openstreetmap.org/search.php?q=lerchenstra%C3%9Fe+35%2C+steinenbronn&format=xml&addressdetails=1&polygon_geojson=1) [Relation 6037273 should be found](http://www.openstreetmap.org/relation/6037273)

Daar wil ik nog wel even verder naar kijken dat zal wat tijd kosten.

Mocht je een snelle work-around willen dan zou ik gewoon w1333851686 van naam en website voorzien.

erik1984 · 2024-11-15T22:04:33.213Z

emvee:

Daar wil ik nog wel even verder naar kijken dat zal wat tijd kosten.

Je bedoelt om zelf een PR hiervoor te gaan maken?

Nu maar voor de snelle oplossing gekozen en naam op het huisjesgedeelte geplaatst.