Service=driveway_link

Kan iemand me vertellen hoe en waar driveway_link gedocumenteerd is?

De enige instantie van “driveway link” die ik kon vinden op de Wiki staat op Tag:traffic_calming=chicane

service=driveway_link komt overigens wel 2526 keer voor volgens Taginfo, maar het schijnt pas heel kort in gebruik te zijn genomen (check de grafiek).

Niet gedocumenteerd.

Na menig topic hier en algemeen op het forum over aansluiting bij T splitsing en aansluiting op sidewalk en cycleway en verder een erf op.
Er waren er bij die gaven deze stukken unclassified, residential en wilde niet routeren over value driveway
Dat zette mij aan het denken, niet routeren over driveway, daar had men een punt alleen de uitvoering. Een aansluiting, maar tevens gebruikt als inrit naar. En dit komt vaak voor, dat de gemeente van de voetganger op het trottoir verwacht hier gebruik van te maken. Zo ook met rolstoel.

Bij het goed leggen van een stad, waar vele trottoirs waren ingetekend, mindere aansluitingen, denk je daar over na, het verschil, hoe alles goed leggen, om bomen en perkjes heen. Waar men verwacht over te steken of de weg verder neemt, via inrit kerbs, goede aansluitingen creëren, doorgaande routes. Waar mag je lopen en waar niet (use_sidepath), en waar heb je een recht om te lopen. Met preset bezig, denk je daar nog meer over na.

Het verschil tussen het inritdeel en het opritdeel.
In BGT wordt dat deel benoemd als inrit.
Daar ligt een juridisch verschil.

De inrit, veelal eigendom van de gemeente, behoort bij "de weg " Wegenwet, een deel dat juridisch openbaar is, men heeft daar een recht om er gebruik van te maken.

Bij de oprit, dat deel op het erf is er sprake van mogelijke feitelijke openbaarheid, daar waar permissive geldt.

Heb ik gebruik gemaakt van driveway_link net zoals er andere op highway -link vormen zijn.

Dat leek mij de beste oplossing. Nu benoemd, is het ook anders te stylen indien gewenst.

En de routering heeft geen last van value driveway.

Zulke overgangen, daar heb je vaak met verschillende ondergronden te maken. En dus knippen om surfacete zetten.

Met preset neem je dat met een one click mee, en is het ingevoerd zoals het erbij ligt.

Ook achter het fietspad naar het erf toe geeft BGT een stuk inrit aan.
Daar heeft men het onderhoud, hoewel de erfeigenaar daar wel eens invulling aan geeft wat betreft bestrating. De grens is eigenlijk het kadastrale perceel.

Een trottoir die aansluit op een inrit en daarna de oprit.


forumpost
Het gaat om het goed intekenen van zulke situaties. (3) driveway_link (niet gestyled)

forumpost

Ik moest even nadenken, maar ik ben het ermee eens. Ik heb ditzelfde ook vaak gedacht. Wat mij tegenhield was dat ik geen bestaande highway value kon bedenken die klopt en die ook nog routeert voor m.n. fietsverkeer, want dat zijn de gebruikers. Dan kwam je bv uit op tertiary omdat de weg tertiary is, maar dat klopt ook niet met de werkelijkheid.

Ik vermoed dat driveway_link ook niet algemeen routeert, maar dat is denk ik een kwestie van profielen. Het zegt in ieder geval wat het is.

Dat klopt, highway=service wel en men kan nu de keuze maken om dat onderscheid te maken.
En dat deel als algemeen routerend aan te merken.

O ja, het is een ATYL toevoeging bij highway=service. Ja, ik kan me hier helemaal in vinden.

OK, bedankt. Kon er al niets van vinden. Op zich nuttig, kan m.i. verder gebruikt worden. Waarom niet groter oppakken en met een proposal komen?

Maar waarom dan als er geen sidewalk en/of fietspad ligt, dus alleen een zuivere driveway?

Wat mij opvalt in deze changeset, is het overmatig opknippen van wegen. Dit lijkt voort te komen uit een fundamenteel verschil in hoe we de fysieke wereld vertalen naar het lijnenmodel van OSM.

Hoewel ik de drang naar een hoog detailniveau goed begrijp, zou informatie over het wegoppervlak van het kruispunt wat mij betreft op de kruispunt-node gemapt moeten worden. Naar mijn idee representeert deze node namelijk de fysieke ruimte die het hele kruisingsvlak inneemt binnen de OSM-graaf.

De lijnen die vanuit deze centrale node vertrekken, representeren vervolgens de weggedeeltes buiten het kruisingsvlak. Door het wegennet op deze manier op te splitsen, geef je in feite aan dat een deel van de aftakkende weg het oppervlak van de hoofdweg heeft, wat feitelijk onjuist is.

Zelf zie ik dit niet als verschil in detailniveau maar echt als een fundamentele data fout van hoe we het detailniveau realiseren.

Ik zou graag jouw argumentatie willen weten in deze toepassing.

5 Likes

Interessant gedachten experiment.
Dit zou wel een hele fundamentele wijziging zijn…

Bijvoorbeeld een nieuw, verplicht “centrale node” type. Een Simple weg heeft immers maar twee nodes die beiden een bepaalde overgang tussen twee wegen aangeven, en ook nog eens gedeeld worden met de wegen er naast.

En ways die meer dan 2 eindpunten kunnen hebben, zie je voorbeeld, maar die zouden gegroepeerd kunnen worden onder de ‘centrale node’.

Weet niet of dat makkelijk wordt, maar bespaart wel de af en toe zeer lange tag lijst consistent te houden bij opgesplitste en later gewijzigde weg segmenten.

(Of misschien toch maar ‘areas met properties’ die overgenomen worden door de daar binnen liggende ways en nodes, en dan de boel al dan niet post-processen tot iets backward compatible)

…
Jouw voorbeeld wordt al snel moeilijk omdat je dan niet meer weet of je moet taggen op de kruispunt node (way met 3 eindpunten), op op de way zelf (niet op het kruispunt deel, maar wel zodra het wegdek wijzigt en het een normale way wordt met 2 eindpunten)

De tijd, die je ergens aan wilt besteden, een proposal of laten gebeuren, wat ook mag, en andere zaken maken, controleren, mappen/taggen.
Op de ene plek meer bruikbaar nuttig voor routering dan op andere plekken, alleen een inrit/oprit waar hetzelfde voor geldt, dezelfde werkwijze hanteren. Dat is ook een keuze. Net zoals de keuze teken je alle inrit/oprit in, of alleen die, die de mapper het meest waardevol vindt. Hoe volledig wil je zijn.

Knip, waar het ligt, topografisch op zijn plaats, een overgang, is een overgang.
Zo ingetekend, kan je de data bewerken naar een set die voor jouw bruikbaar is in de applicatie. Omgekeerd, kan je geen set maken waar het topografisch goed ligt. Als het knippunt niet aanwezig is. We hebben een lijnmodel in gebruik voor wegen, dus knip je de lijn.

Zoals vele zaken, waarvoor we de lijn kunnen knippen.
Ik neem als voorbeeld, het niet separate intekenen van sidewalk, sidewalk aan deze lijn hangen, met al die surface overgangen op het trottoir bij alle inrit/oprit op sommige plaatsen. Dan kies ik toch liever voor een separate ingetekend sidewalk en zet daar de knips. Veel beter controleerbaar en optisch op zijn plaats.

De naam blijft op de weg staan, ook op dat kleine stukje.

1 Like

In dit geval ben ik het met je eens, omdat het kleine stukje weg geen aparte functie heeft. In het geval van particuliere driveways die met een publiek stukje verbonden zijn met de weg, wat ook door ander verkeer gebruikt wordt, vind ik het wél juist om de verbinding apart te taggen.

De surface boeit me dan minder, alleen voor de surface zou ik het niet doen, maar als je toch opknipt kan je dat net zo goed ook aanpassen.

Hier nog een voorbeeld waar splitsen MI nodig is:

De Eelderstraat is een woonerf, maar bij het fietspad hebben voetgangers geen speciale rechten meer, daar moeten ze gewoon voorrang geven. Dus dat stuk is geen living_street meer. Ik zou het denk ik een residential geven en de voorrang expliciet taggen. De crossing van de fietsers over de Eelderstraat is een crossing:continuous=yes met crossing:markings=surface.

PS Heb dat inmiddels zo gedaan.

Deze manier van interpreteren kun je niet zo algemeen op alle soorten tags toepassen, in ieder geval niet op tags met een plaatsgebonden fysieke interpretatie zoals surface. Een weggedeelte vertegenwoordigt in eerste instantie zichzelf en niet een ander weggedeelte verderop. Kruispuntvlakken hebben in het lijnenmodel nu eenmaal geen infinitesimale lengte.

Het deel van de lijn dat binnen het kruispuntvlak ligt, correspondeert met de afstand die je binnen het kruispuntvlak moet afleggen, en deze afstand leg je af over asfalt. Dit is binnen het lijnenmodel de logische manier om aan te geven tot hoe ver het asfalt reikt, ongeacht of het asfalt op de rand van het kruispuntvlak ophoudt, enkele meters daarna, of een heel eind verderop.

Mijn stelling is dat de fysieke footprint (breedte) van een weg binnen een abstract lijnenmodel géén invloed heeft op een aftakkend lineair element, dit gaat dus puur om het snijvlak en niet om wat er buiten het kruispunt gebeurt. Een stukje weg tussen bijvoorbeeld de rijbaan en het fietspad kan wel andere attributen hebben.

Hieronder een voorbeeld van hoe je bij deze conclusie kan komen:

Neem een fysieke weg met een breedte. Om hier een lijn van te maken, trekken we de randen naar het midden tot er één lijn overblijft. Deze stap van 2D naar 1D werkt voor een enkele weg probleemloos.

Beeld dit nu in voor twee losse wegen die elkaar kruisen. Als we beide vlakken ‘platmaken’ naar hun hartlijnen, snijden die lijnen elkaar in exact één punt: de centrale node. Dat punt representeert het gehele kruispuntvlak.

Leggen we dit lijnenmodel vervolgens weer over een luchtfoto of BGT, dan lijkt het alsof het eerste stukje van de aftakkende lijn over het oppervlak van de hoofdweg loopt. Maar deze overlap is een visueel bijproduct van het terug projecteren van een 1D-netwerk op een 2D-achtergrond. Binnen de logica van het lijnenmodel bestaat die overlap niet, die ruimte bestaat niet meer.

@JeroenvanderGun Ik begrijp je redenering, en in bepaalde contexten klopt het, bijvoorbeeld als je het bewandelt in een vlakgericht model, een 3D game of in de echte wereld, leg je die eerste meters daadwerkelijk af over het asfalt van de hoofdweg. Daar telt het fysieke oppervlak op de exacte coördinaat.

Waar we fundamenteel verschillen, is de filosofie achter het lijnenmodel: is het een topologische abstractie van het wegennetwerk, of een 1-op-1 geografische projectie van de fysieke ondergrond op een lijn?

Het argument dat de lijn de afstand over het asfalt representeert, haalt vlakgericht en lijngericht door elkaar. Het kruisingsvlak zit in het lijnenmodel al volledig in de centrale node.

De afstand die de lijn virtueel ‘aflegt’ binnen de footprint van het kruispunt is enkel een geometrische noodzaak om de lijnen aan elkaar te verbinden, niet een zelfstandig wegvak. Door die meters apart te taggen, geef je een bijproduct van de abstractie (de breedte van de hoofdweg) onterecht de status van een eigen wegsegment.

Als we dit consistent doortrekken, raak je al snel verstrikt in rare combinaties.

Bijvoorbeeld:

Moet een zijweg met aan beide kanten een stoep (sidewalk=both) op die eerste 2 meter asfalt sidewalk=no krijgen omdat er op het kruispuntvlak fysiek geen stoep ligt?

Omdat de zijweg haaks op de hoofdweg staat, wordt de breedte van de zijweg gemeten in de lengterichting van de hoofdweg. Als je de fysieke ondergrond volgt, zou de ‘breedte’ van dat stukje lijn gelijk zijn aan de lengte van de hoofdweg.

Dat hetgeenr wat je zelf bedacht en ingevoerd hebt, begrijpelijk is voor een ander.