Voorstel: ontwikkel project

Graag zou ik een vlak willen aanmaken waaruit duidelijk naar voren komt dat het gemarkeerde gebied (her) ontwikkelingsgebied betreft.
Tags daarbij:
Project owner
Project name
Project:website
Project termijn
Project area access waaruit blijkt welke [verkeers]gebruikers toe- en/of doorgang hebben tijdens het lopende project.

Doel: door ontwikkel projecten te markeren wordt daardoor een gebied onttoegankelijk tenzij bij access aan gegeven wordt welke groep gebruikers wel toe of doorgang hebben. zodat als je als verkeersgebruiker van a naar b wil bijvoorbeeld OSM Carto rekeninghoudend met ook ontwikkelproject obstakels toch een goede route bepaald kan worden.

Voorbeeld: door bouwwerkzaamheden (zowel in geval vangebouwen als wegen) worden straten geblokkeerd bij ontwikkel project Houtplein Haarlem. Daarbij is niet van belang hoe (verkeers)groepen toe-/doorgang hebben in het ontwikkel project gebied maar dat ze wel of geen toegang krijgen, zodat als je als verkeersgebruiker van aan naar b wil bijvoorbeeld OSM Carto rekeninghoudend met ook ontwikkelproject obstakels toch een goede route bepaald kan worden.
Wie is voor ?

Kun je dat niet doen met Conditional restrictions - OpenStreetMap Wiki ?

Ja dat kan voor de Project area access tag een goede oplossing zijn.
Ik wil een universele oplossing voor bouwprojecten zowel wegenbouw als gebouw bouwprojecten immers het gaat er niet om wat er gebouwd word maar dat het projectvlak het obstakel vormt voor doorgang.
Project Houtplein is een goed voorbeeld: door project fasering was elke keer een ander deel van het project een obstakel voor openbare ruimte gebruikers… Dan is het wel mooi meteen n.a.v. het projectvlak wegen te blokkeren zodat routing programma’s daar rekening mee houden.
Zie het als een wegversperring maar dan voor het hele vlak.

Edit: laatste zin

Dit lijkt in te gaan tegen de richtlijn Don’t map temporary events and temporary features. Welke paden (deels) geblokkeerd zijn verandert vaak sterk gedurende een bouwproject. Data-gebruikers werken vaak met oudere OSM data, en voor hen is dit vast onpraktisch.

Naast de conditional restrictions kun je ook een landuse=construction mappen voor “projectvlakken” zoals je ze noemt.

Landuse construction kan maar je wilt zo min mogelijk wegvegen kwa wegen & gebouwen in 1ste instantie.

Projecten in Haarlem door de complexiteit & inspraak duren minimaal 3-kwart jaar… Dat noem ik niet tijdelijk…
Bovendien map je niet de omleidingen wat echt tijdelijk is maar het gegeven (zie het als black box) dat het project de blokkade vormt.

Zo’n “black box” is lang niet altijd een duidelijk verifieerbaar fysiek object op de kaart. Een bouwproject is een proces. Op zichzelf zegt zo’n “black box” weinig over de situatie ter plaatse.

Naar mijn mening geven juist de project keys duidelijkheid aan, als voorbeeld Houtplein: Je weet dat er gebouwd wordt en daardoor vertragingen kan verwachten… Op dit moment zijn fietsers & voetgangers nog steeds welkom tussen het stuk: grote houtbrug & houtplein. Auto’s daarentegen kunnen niet meer hun weg vervolgen in dat stuk…
De duidelijkheid is een verder niet toe doend bouwproject vlak…

In waze en google maps kun je prima weg afsluitingen en tijdelijke situaties doorgeven zodat verkeer wordt omgeleid. OSM is hier niet voor, zie de berichtjes en linkjes van @Friendly_Ghost.

1 Like

Dan is dus zelfs de landuse oplossing geen oplossing…
Houd het weer helemaal op…
Beetje het “computer says no” concept.

Je kan een bouwterrein (landuse=construction) toevoegen. Daar kunnen de meeste van de project-tags die je voorstel op getagd worden.

Ik waardeer de aangedragen landuse=construction oplossing maar daar kan ik niet de minimale tags:

  1. access (om openbare ruimte gebruikers mee aan te geven die wel toe- en/of doorgang hebben)
  2. operator:website (url-verwijzing om relevante info te kunnen lezen)

in kwijt…

Zonder punt 1 aan te kunnen geven geef je foutieve info namelijk dat een gebied totaal niet toegankelijk is…

@Dillen_GJ Als ik het goed begrijp haal ik het volgende uit je voorstel;

1) Een gebied (area) markeren. Dit gebied kan huidige bouw zijn, maar ook een (her)ontwikkelsgebied.
Check de tags Tag:landuse=brownfield - OpenStreetMap Wiki // Tag:landuse=greenfield - OpenStreetMap Wiki // Tag:landuse=construction - OpenStreetMap Wiki hiervoor. Kijk ook zeker even naar de https://wiki.openstreetmap.org/wiki/Key:proposed tag! Volgens mij kom je met deze combinaties een heel eind.

2) Een van bovenstaande gebieden complementeren met extra project informatie tags.
Het eventueel opnemen van extra project informatie lijkt mij wel een goed idee, ik denk dan voornamelijk aan de website van het project met alle details. Handig om snel te checken of de *=construction nog actueel is. Op de wiki van de https://wiki.openstreetmap.org/wiki/Key:proposed tag zie je ook dat er wordt geopperd met start/end dates “a further tag could be added to illustrate the expected beginning of construction and planned opening date.” . Misschien kun je daar eens aanhaken. Ik ben zelf geen voorstander van dit soort details in OSM, hoevaak loopt een project wel niet uit, begint eerder, later… naja… Dat wordt een rommeltje.

3) Tijdelijke omleidingen/restricties in deze betreffende gebieden
Dit is eigenlijk een “dynamische laag” boven op OSM. Diverse navigatie apps bieden dit al aan, zoals Waze, Google Maps, TomTom, enz…ook in OSMand kun je omleiding instellingen. Dit leunt heftig op actuele GPS data, input van gebruikers, feedback, software die er mee om moet gaan…Dit soort tijdelijke (verkeer)situaties horen niet thuis in de OSM database. Je bent natuurlijk vrij om zelf hier iets omheen te bouwen in een eigen app, website oid. :wink:

Kun je hier iets mee of zit ik er volledig naast? :stuck_out_tongue:

3 Likes

Ja dat is precies wat ik bedoel en idd laten we gewoon beginnen met de 2 tags die ik eerder aangeven heb: website verwijzing & toegangspermissie voor verkeersgroepen door de bouwende operator

Ik heb een overpass gedraaid en ik zie dat de website=* tags al veel gebruikt worden icm construction. Zie hier de query .

Ook Overpass gedraaid voor de operator tag, ook deze wordt al veelvuldig gebruikt icm construction. Zie hier.

In plaats van project:website, zoals je voorstelt, zou je dan operator:website kunnen gebruiken. Mijn voorkeur gaat uit naar keep it simple en gewoon website:=* gebruiken. Maar dat ben ik.

Wel grappig, je voorstel wordt eigenlijk al veelvuldig gebruikt, het staat alleen niet op papier (of althans, niet te vinden ) . Mocht je tijd en zin hebben… :wink:

Top !
Ik mis nog 1 belangrijke: access-groep aan kunnen geven anders had nl landuse=construction DE oplossing geweest en had ik geen voorstel ingediend… :wink:

Overpass met acces=* voorbeelden op landuse=construction kun je hier vinden.

operator:website is eigenlijk bedoeld voor de website van de operator. Stel je hebt een bouwproject met de naam “Weidevelden” gebouwd door aannemer “Jan en Piet Aannemers”. Dan zouden de tags zoiets zijn:

(Deze websites bestaan niet echt)

2 Likes

In het Houtplein project zou dit nu een werkbare weergave zijn zonder een voorstel te hoeven indienen denk ik:

  1. landuse= construction
  2. website= Herinrichting Houtplein en omgeving | Gemeente Haarlem
  3. operator:website= https://gemeentebestuur.haarlem.nl/bestuurlijke-stukken/2018750582-2-Bijlage-A-DO-Herinrichting-Houtplein-eo-2.pdf ; Herinrichting Houtplein Haarlem | Dura Vermeer
  4. Description= gereguleerde toegang door de operator voor voetgangers & fietsers
  5. Name= Herinrichting Houtplein e.o. te Haarlem

Waarbij ik eigenlijk niet weet of je 2 urls bij punt 3 mag weergeven.

Wie wil wat meedenk reaktie’s geven op bovenstaande ?

Er is ook de url=* tag als aanvulling op website. Scheelt een ;

1 Like

@Dillen_GJ is het een idee om eerst te focussen op de huidige tags die beschikbaar zijn, zodat je daar wat meer bekend mee wordt? Dat je het voorjezelf wat eenvoudiger maakt. Dus in het geval van landuse=construction pak je de wiki erbij en ga je kijken welke tags er zijn. Die kun je invullen. Kijk ook naar voorbeelden in je omgeving hoe andere mappers het doen. Je begint dan “klein” en ‘‘afgebakend’’. Je krijgt meer inzicht en raakt vertrouwd met de (on)mogelijkheden binnen OSM. Na een tijdje kun je dit stapje voor stapje gaan uitbreiden. Dan komen de voorstellen en ideeën vanzelf.

1 Like