capacity:* maakt al deel uit van het totaal. Met capacity:disabled=30 samen met capacity=30 zeg je dat er in totaal 30 parkeervakken zijn die allemaal exclusief voor gehandicapten zijn. Weet je zeker dat dat klopt?

Zo komt iemand die op "Jacobus Hoeve" zoekt op de kaart straks ook daar terecht.

Als je meer details over de camping wil invoeren, dan zou je ook eens kunnen kijken naar de tag tourism=caravan_site:

osm.wiki/Tag:tourism%3Dcaravan_site

De simpele manier is om een node een beetje in het midden of wat richting de ingang die tag te geven, of, netter maar meer werk, een gesloten lijn om de hele camping te tekenen en die te gebruiken. Op die node of lijn voeg je dan naast tourism=caravan_site ook de naam toe (name=Jacobus Hoeve) en details zoals de website.

Hi,

Je hebt netjes de bos- en graslaag van het weggetje gehaald. Daarmee lijkt op de kaart inderdaad het weggetje ingetekend te zijn, maar vergeet niet ook de lijn in te tekenen waarmee je aangeeft dát het een weg is.

Ik heb dat hier als voorbeeld een stukje voor je ingetekend:

osm.org/changeset/86939439

Je zou alle verharde wegen op de camping op die manier in kunnen tekenen met de highway=service en access=private tags (omdat niet iedereen zomaar het terrein op mag rijden voorbij de slagboom tenslotte).

Ja, dat is qua tagging net. Er zit nog een schoonheidsfoutje in, en dat is dat het vlak met surface=grass nu ook onder het vlak met tegels ligt. Ik heb bij wijze van voorbeeld een aanpassing gedaan waarin dat verholpen is:

osm.org/changeset/86936836

Het stukje speeltuin waar gras ligt is nu een eigen vlak, en het hek volgt nu de door de gemeente ingemeten lijnen van de Basisregistratie Grootschalige Topografie (BGT). Die laag mogen wij in OSM ook gebruiken bij het intekenen van objecten. Mocht je dat interessant vinden, dan kun je eens een blik werpen op de JOSM-editor, waarin deze laag ingeladen kan worden onder de kaart. JOSM geeft je een stuk meer controle dan de webeditor van OSM, maar voor eenvoudige details is het geen vereiste. Ervaren mappers doen eigenlijk alles met JOSM.

Meer informatie over JOSM en de BGT-laag vind je onder andere hier:

https://forum.openstreetmap.org/viewtopic.php?id=64644

Stel daar ook gerust vragen.

Let trouwens op met het intekenen van stoepen. De meeste mapper laten die weg bij straten in woonwijken, omdat het best lastig is ze goed in te tekenen en niet direct veel toevoegt. Het is geen probleem om vanaf de gates direct een highway=footway naar de straat te trekken.

Als laatste kun je ook nog de twee gates met een highway=footway verbinden met de twee straten. Dan kan een routeplanner je zo naar de speeltuin sturen.

Wat ik zelf zou doen is de multipolygon-relatie verwijderen (die klopt nu niet namelijk), en de buitenste ring leisure=playground geven aangevuld met barrier=fence, fence_type=chain_link, en
height=1.

De bovenste ring:

landuse=grass
wheelchair=limited

De onderste ring:

highway=pedestrian
area=yes
surface=paved
wheelchair=yes

Hi,

Voor het grootste deel klopt het zo, maar er is iets een beetje raar gegaan met de leisure=playground: die is nu als een multipolygon en een los vlak (het betegelde deel) ingetekend. De leisure=playground tag zou ik alleen op het buitenste vierkant zetten.

leisure=playground zit ook per ongeluk op het speelkasteel. Daar hoort playground=structure in plaats van leisure=playground.

Verder mag je access=yes weglaten. Die is namelijk impliciet.

Vaak hebben gemeentes lokale regelgeving die alle speeltuinen verboden terrein voor honden maakt. Als dat in Velp ook het geval is kun je dog=no toevoegen.

Dank je! Leuk dat het opvalt. Dit is ook wel een mooi wijkje op een kaart met de strakke lijnen en het pleintje in het midden.

Ah, je had het kaartje ook gevonden. :)

Fijn van de tekenaar dat hij/zij de outline van het bestaande huis 4c ernaast op de kaart had gezet, dat maakte het wel eenvoudig om te zien waar die project neergezet werd.

Bespoddelijke naam verder.

Deze JOSM-plugin die ik gemaakt heb kan handig zijn voor parkeervakken:

https://github.com/JOSM/josm-gridify

Ik heb hem ook met parkeervakken in het achterhoofd geschreven. Mogelijk kende je hem al, maar hij scheelt een hoop werk. Je kan hem gewoon vanuit JOSM installeren.

Dat laatste heb ik net doorgevoerd trouwens:

osm.org/changeset/86618395

Ik heb daar bij wijze van experiment twee jaar geleden wel een parkeerrelatie aangemaakt, maar het voegt vooralsnog niets toe aan de data.

Met een multipolygon als amenity=parking doe je hetzelfde, maar is het parkeerterrein opgeknipt in meer delen. Conceptueel is het hetzelfde, maar op de kaart impliceer je er mee dat de delen die niet als amenity=parking zijn ingetekend niet exclusief voor parkeren worden gebruikt.

Dit is een mooi voorbeeld:

osm.org/relation/8271013

Parkhoven is een zorginstelling met een moderne terreininrichting waar een klassiek parkeerterrein ontbreekt. De parkeervakken zijn verdeeld over het terrein. Door de amenity=parking als één entiteit in te tekenen is het ook voor navigatiesoftware en renderers als één ding te herkennen, ook als is het verspreid over een gebied.

osm.org/relation/8271013

Het zou daar onwenselijk zijn om een enkel groot parkeervlak om de zorginstelling te trekken, want dat is niet hoe het terrein gebruikt wordt. Het stukje in het noordoosten van het terrein wat nu uit twee vlakken bestaat zou trouwens wel als een vlak ingetekend kunnen worden, omdat het stukje weg daar exclusief voor parkeertoegang gebruikt wordt.

Dit is een voorbeeld van een parkeeplaats die als vlak is ingetekend zonder MP:

osm.org/way/815703905

De parking_spaces vallen ruimtelijk binnen de parking. Dit is de simpelste manier om een parkteerterrein met parkeervlakken te tekenen.

(osm.org/changeset/86597266)

Ik zit even te kijken, maar ik vrees dat ik de fout niet zie als ik de gangbare wiki-definities volg. amenity=parking mag je samenvoegen met een MP als ze een logisch geheel vormen:

wiki: “Standard method to draw parking […] that consists of disjointed areas […] is to use multipolygons.”

Het voordeel van de amenity=parking MP is dat hij als één entiteit optreed.

De losse parking_spaces worden zelden in relaties opgenomen, dat wordt op de wiki ook benoemd. Wel horen ze ruimtelijk binnen een amenity=parking te vallen, maar dat was hier ook het geval.

Als ik deze changeset revert in JOSM zie ik geen fouten qua tagging.

Haal je misschien de relatietypes door elkaar? De site=parking relatie is correct, maar mist nu de overkoepelende amenity=parking, maar relation=parking wordt niet vaak toegepast buiten heel complexe parkeerterreinen, en lijkt ook nog geen brede acceptatie te hebben binnen de gemeenschap:

wiki: “It has been suggested that the type=site relation can be used with site=parking to group parking spaces and parking entrances together to form one parking facility, as described on Proposed features/parking. Currently however there is almost no support for this among either mappers or data consumers […]”

De MP die ik daarvoor gebruikte was verder correct los van de rakende ringen die je vond.

Vreemd dat JOSM daar niet over valt. Ik zal er op letten.

Kwam dat mailtje aan? Mijn mail-client deed wat moeilijk over het doorsturen ervan, misschien omdat het Word-documenten zijn.

Ja dat lijkt me prima. De adressen zijn ook Molkenkelder, de straat heet alleen niet zo volgens het besluit uit 2014. Het zou best kunnen dat ze de straat later weer hernoemen natuurlijk; we zien vanzelf wel een keer een bordje verschijnen. Ik zal je de stukken van de gemeente uit 2014 even doorsturen via de mail; die heb ik deze week opgevraagd bij de gemeente omdat ze blijkbaar nooit on-line zijn gezet.

Waarom de edit van osm.org/node/48202225 helemaal in Leeuwarden in deze changeset?