Re: [OSM-talk-be] trunk crossroads and cyclerouting

[Ben Laenen]

Klaas Gadeyne wrote:
> I'm not sure I understand you, unless you've made a typo:  With
> "crossing roads", I assumed you meant the Celestijnenlaan
> ( and northern
> counterpart).  However, these both are tagged as residential (and not
> as unclassified)??  [*]

Yeah, I didn't actually go check the tagging, just guessed on the white road 
being unclassified. If it's residential then tag the small bit residential as 
well.

Ben

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] trunk crossroads and cyclerouting

[Klaas Gadeyne]

On Mon, Dec 6, 2010 at 12:41 PM, Ben Laenen  wrote:
> Klaas Gadeyne wrote:
> > This way is currently tagged as trunk_link
> > .  However, (at
> > least in Belgium) trunk roads are prohibited for bicycles.
>
> Well, yes and no. Yes for 99% of trunks in Belgium, but there are exceptions,
> particularly at crossroads where one wouldn't downgrade small pieces of road.
> Take for example a crossing between two dual carriage roads, one trunk, the
> other primary: you wouldn't split the trunk at the crossing to downgrade it on
> that little bit to primary.
>
> I wouldn't use links for these bits either: links are primarily for ramps (op-
> en afritten) to the road, like those on motorways.
>
> > So it seems like trunk_link ways are also "bicycles prohibited".  Does
> > anyone have a suggestion/thought on how to fix this?
> >
> > - Changing trunk_link into primary_link seems weird (and only solves
> > the problem locally)
>
> I usually tag these small ways between two lanes of a dual carriage road with
> the same classification of the crossing roads, in this case
> highway=unclassified. But there's no strict rule on this AFAIK, even though we
> could really use one...
>
> (Also, preferably keep this little way as a separate way, i.e. don't join with
> the crossing roads)

I'm not sure I understand you, unless you've made a typo:  With
"crossing roads", I assumed you meant the Celestijnenlaan
( and northern
counterpart).  However, these both are tagged as residential (and not
as unclassified)??  [*]

(Note: Tagging the small way as residential seems also the solution
Gerard suggests in his reply)

[snip section about possibly adding other tags]

Regards,

Klaas

[*] In fact, you are partly right in the sense that way 72912809 (in
fact the whole Celestijnenlaan south of Koning Boudewijnlaan)
shouldn't be tagged as residential, as it's full of university
buildings and companies...

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] layer probleempje

[Ben Laenen]

Gerard Vanderveken wrote:
> Als het fietspad een scheiding heeft die meer is dan een geschilderde
> lijn. zoals op de stoep ligt of er ligt 30cm goot of kassei tussen, map
> ik het altijd als track.
> Maar door de verlenging verderop, is het misschien meer zinvol om de
> fiets- en voetpaden als afzonderlijke ways te mappen, zoals nu reeds met
> het fietspad rechts.

Bing nodigt inderdaad uit om zowat alle fietspaden met aparte ways te mappen, 
maar wil hier wel op hameren: werk gedetailleerd en verbind alles correct met 
de andere ways aan de kruispunten. Ook geen fantasietjes als bicycle=no op de 
weg zelf als je er een fietspad naast getekend hebt alsjeblieft.

Te vaak zie ik enkele parallelle lijnen met de weg die het fietspad 
voorstellen, maar die voor de rest bvb. alle kruispunten negeren.


Wat betreft afzonderlijke voetpaden, dit is vaak veel moeilijker en volgens 
mij enkel iets wat we deftig kunnen doen met wat bekend staat onder 
micromapping: alles als polygonen ipv ways mappen. Voorlopig niet te veel van 
aantrekken tenzij het voetpad echt zijn eigen loop volgt afzonderlijk van de 
weg en het fietspad.

Ben

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] trunk crossroads and cyclerouting

[Maarten Deen]

On Mon, 6 Dec 2010 12:41:25 +0100, Ben Laenen 
wrote:

> I usually tag these small ways between two lanes of a dual carriage
> road with the same classification of the crossing roads, in this case 
> highway=unclassified. But there's no strict rule on this AFAIK, even
> though we could really use one...

Tag it according to the traffic that runs over it. If the crossing road
is a residential road, tag the part between the two carriageways as
residential. Is it a cycleway, tag it as cycleway.

I think the basic rule can be made as such: if a way crosses another
way, do not change the tagging to match the crossing way.

So the example Klaas gave is IMHO an example of incorrect tagging.

Maarten

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] layer probleempje

[Gerard Vanderveken]

Marc Portier wrote:


Gerard,

net ook de josm upgrade gedaan en met de bing assistentie is het
effectief bijzonder prettig werken

Op 3 december 2010 16:08 heeft Gerard Vanderveken  het
volgende geschreven:
 


Wat eerst opvalt is de geringe precisie voor ligging en loop van de straten
(Er was blijkbaar veel wind en de satellieten hingen scheef :-D ).
Het fietspad ligt vrij goed.
http://www.openstreetmap.org/browse/way/81059334
De opgaande weg ligt er normaal  vlak naast.
http://www.openstreetmap.org/browse/way/81059339
Maar op de kaart wordt dat een tiental meter, wat teveel is.
   



ja, dat was me ook opgevallen, maar ik hou me doorgaans op bestaande
nodes van anderen nogal straf in (ben ook nog maar net begonnen in
josm, en zonder de sat-pics)

Wij zijn misschien wat te verwend, daar ik steeds Yahoo in mijn regio 
had. Maar met Bing en jouw tracks in de hand, kan je hier en daar wel 
met wat meer zekerheid de ligging bijwerken.



Er is natuurlijk wel een zekere afstand tussen, want de mapping gebeurt as
naar as, dus halve straatbreedte plus halve padbreedte.
De weg staat nu als highway= residential, maar ik zou misschien eerder
kiezen voor highway= service en het fietspad daar niet apart maar als
cycleway:right =track.
   



dank voor de tip, er ligt ook nog een voetpad langs trouwens, dat
wordt dan ook nog een footway=right?

verderopn (voorbij de parking) lopen fiets-en voet-pad trouwens gewoon
door over het oude traject van de weg waar ook de tram nog rijdt
(wagens kunnen niet meer verder)

en ik vind net ook dit:
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycleways
(de 'appropriate barrier' is in dit geval vooral de verhoging van het
fietspad tov het wegdek, niet echt 1m afstand dus)
 

Als het fietspad een scheiding heeft die meer is dan een geschilderde 
lijn. zoals op de stoep ligt of er ligt 30cm goot of kassei tussen, map 
ik het altijd als track.
Maar door de verlenging verderop, is het misschien meer zinvol om de 
fiets- en voetpaden als afzonderlijke ways te mappen, zoals nu reeds met 
het fietspad rechts.



Omdat nu de drie wegen elk apart een brug lijken te hebben, zou ik er eerder
voor kiezen om de hele oppervlakte als parking (of is er een betere tag om
een open ruimte/plein aan te geven) aan te duiden, met daarop de wegen,
allen in layer 1.
De onderliggende weg , Slachthuiskaai zou ik op layer 0 als tunnel aangeven
op zijn lengte (20m).
   



goed idee, ik kijk ernaar (een dezer)
bedankt voor de tip.


Gewoon taggen met area=yes


http://www.openstreetmap.org/browse/way/81059342
en ook de andere wegen die er verderop onderdoor lopen, zoals de spoorweg en
de weg naar de terminal.
De resulterende kaart zal mi. dan korrekter kunnen worden geinterpreteerd.

Het is logisch dat de trap vedwijnt in de rendering, want zijn lengte is
veel te kort (nu 5 meter).
http://www.openstreetmap.org/browse/way/86960775
Als ik zie op satelliet, dan is zijn lengte minstens 10 meter, (logisch ook,
daar hij een hoogte van 5-6 meter maakt en ook nog twee platformen bevat),
daarbij loopt hij over een voetpad tot aan de as van de weg,  wat ook nog
eens 5 meter maakt. Dus hij is drie keer langer dan gemapt.

   



mijn fout, denk dat ik me vooral laten misleiden heb door de weg die
(nu via bing duidelijk) te hoog naar het noorden ligt, de combo met
mijn gps track heeft me wat oneigenlijk doen schipperen denk ik

ik kijk het in alle geval mee na straks

Soms is een GPS heel onnauwkeurig als je tegen een gebouw staat. eens de 
straat oversteken, kan in dat geval een nauwkeurigere positie opleveren.



Apropos, je vermeld "met PM"   zo terloops dat het klinkt alsof ik zou
moeten weten wat dat betekent :-)  (wat niet het geval is, sorry) Als
beginner leer ik graag bij, alvast bedankt.
 


Het berichtensysteem in Openstreetmap (Personal Messages)
http://www.openstreetmap.org/message/new/ghia

mvg
Gerard aka ghia


groetjes,
-marc=

 


mvg
Gerard.

   

 

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] trunk crossroads and cyclerouting

[Ben Laenen]

Klaas Gadeyne wrote:
> This way is currently tagged as trunk_link
> .  However, (at
> least in Belgium) trunk roads are prohibited for bicycles.

Well, yes and no. Yes for 99% of trunks in Belgium, but there are exceptions, 
particularly at crossroads where one wouldn't downgrade small pieces of road. 
Take for example a crossing between two dual carriage roads, one trunk, the 
other primary: you wouldn't split the trunk at the crossing to downgrade it on 
that little bit to primary.

I wouldn't use links for these bits either: links are primarily for ramps (op- 
en afritten) to the road, like those on motorways.

> So it seems like trunk_link ways are also "bicycles prohibited".  Does
> anyone have a suggestion/thought on how to fix this?
> 
> - Changing trunk_link into primary_link seems weird (and only solves
> the problem locally)

I usually tag these small ways between two lanes of a dual carriage road with 
the same classification of the crossing roads, in this case 
highway=unclassified. But there's no strict rule on this AFAIK, even though we 
could really use one...

(Also, preferably keep this little way as a separate way, i.e. don't join with 
the crossing roads)

> - Altering the "bicycles prohibited behaviour" of trunk_link sections
> seems to be an option, but I don't know if this is the best thing to
> do and whom to contact for that?

It's just something we as osm-be agree on (or not), routers etc should follow 
what we agree on (but nowadays often don't of course since they only have one 
set of rules for the entire world).

In the best case you'd have other tags on the road telling if it blocks access 
or not, like
* motorroad=yes for "autoweg" (original meaning for trunk in Belgium, but 
we've added other roads that block access to pedestrians and cyclists to 
trunk, and on the other hand have "autowegen" that aren't classified as trunk)
* foot=no, bicycle=no, moped=no if there are traffic signs for these

If all trunks had these tags it'd be safe to allow pedestrians and cyclists on 
trunks *by default*, but that's not the case by far, so we need some other 
single magic tag that says this. I can only think of motorroad=no for this.

Greetings
Ben

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] layer probleempje

[Marc Portier]

Gerard,

net ook de josm upgrade gedaan en met de bing assistentie is het
effectief bijzonder prettig werken

Op 3 december 2010 16:08 heeft Gerard Vanderveken  het
volgende geschreven:
> Nu Bing ook in mijn JOSM beschikbaar is als satelliet achtergrond (zie Bing
> thread), heb ik eens een blik geworpen op je probleem.
> Met bing.com/maps en tilt view can je ook vanuit zijwaartse richtingen
> kijken en daar lijkt mij die hele parking op een soort dam/viaduct te
> liggen.

jap, het is een oude viaduct, sinds paar jaar herbestemd als parking

> Wat eerst opvalt is de geringe precisie voor ligging en loop van de straten
> (Er was blijkbaar veel wind en de satellieten hingen scheef :-D ).
> Het fietspad ligt vrij goed.
> http://www.openstreetmap.org/browse/way/81059334
> De opgaande weg ligt er normaal  vlak naast.
> http://www.openstreetmap.org/browse/way/81059339
> Maar op de kaart wordt dat een tiental meter, wat teveel is.

ja, dat was me ook opgevallen, maar ik hou me doorgaans op bestaande
nodes van anderen nogal straf in (ben ook nog maar net begonnen in
josm, en zonder de sat-pics)

> Er is natuurlijk wel een zekere afstand tussen, want de mapping gebeurt as
> naar as, dus halve straatbreedte plus halve padbreedte.
> De weg staat nu als highway= residential, maar ik zou misschien eerder
> kiezen voor highway= service en het fietspad daar niet apart maar als
> cycleway:right =track.

dank voor de tip, er ligt ook nog een voetpad langs trouwens, dat
wordt dan ook nog een footway=right?

verderopn (voorbij de parking) lopen fiets-en voet-pad trouwens gewoon
door over het oude traject van de weg waar ook de tram nog rijdt
(wagens kunnen niet meer verder)

en ik vind net ook dit:
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycleways
(de 'appropriate barrier' is in dit geval vooral de verhoging van het
fietspad tov het wegdek, niet echt 1m afstand dus)


> Naast de aflopende weg ligt er eigenlijk nog gedeeltelijk een derde weg die
> nog niet gemapt is.

en ook vooral als extra parking gebruikt in de praktijk

> De Parking ligt binnen de twee wegen.
> http://www.openstreetmap.org/browse/way/86989968

klopt, herbestemming dus van de oude middenberm + linkerrijstroken in
beide richtingen

> Omdat nu de drie wegen elk apart een brug lijken te hebben, zou ik er eerder
> voor kiezen om de hele oppervlakte als parking (of is er een betere tag om
> een open ruimte/plein aan te geven) aan te duiden, met daarop de wegen,
> allen in layer 1.
> De onderliggende weg , Slachthuiskaai zou ik op layer 0 als tunnel aangeven
> op zijn lengte (20m).

goed idee, ik kijk ernaar (een dezer)
bedankt voor de tip.
(mental note to self: de one-way in de tunnel niet vergeten)

> http://www.openstreetmap.org/browse/way/81059342
> en ook de andere wegen die er verderop onderdoor lopen, zoals de spoorweg en
> de weg naar de terminal.
> De resulterende kaart zal mi. dan korrekter kunnen worden geinterpreteerd.
>
> Het is logisch dat de trap vedwijnt in de rendering, want zijn lengte is
> veel te kort (nu 5 meter).
> http://www.openstreetmap.org/browse/way/86960775
> Als ik zie op satelliet, dan is zijn lengte minstens 10 meter, (logisch ook,
> daar hij een hoogte van 5-6 meter maakt en ook nog twee platformen bevat),
> daarbij loopt hij over een voetpad tot aan de as van de weg,  wat ook nog
> eens 5 meter maakt. Dus hij is drie keer langer dan gemapt.
>

mijn fout, denk dat ik me vooral laten misleiden heb door de weg die
(nu via bing duidelijk) te hoog naar het noorden ligt, de combo met
mijn gps track heeft me wat oneigenlijk doen schipperen denk ik

ik kijk het in alle geval mee na straks

> Er is blijkbaar nog een reliek van een knooppunt
> http://www.openstreetmap.org/browse/node/1012467813
> Te wissen?
>

lijkt me idd het geval

> Voor de Kusttram is er een brug gemaakt
> http://www.openstreetmap.org/browse/way/26469322
> die het huidige traject verdubbelt.
> http://www.openstreetmap.org/browse/way/68610996
> Dit moet ingepast worden.
> Dit is ook het geval met
> http://www.openstreetmap.org/browse/way/59211807
> en
> http://www.openstreetmap.org/browse/way/68610999
> en
> http://www.openstreetmap.org/browse/way/68610997
> Ik attendeer  BDROEGE met PM op deze situatie.
> http://www.openstreetmap.org/user/BDROEGE
>


hij/zij heeft ondertussen al een en ander aangepast merk ik
http://www.openstreetmap.org/browse/changeset/6538707

een dezer ga ik dan zelf met bing in de hand ook nog je suggesties van
hierboven toevoegen.

Apropos, je vermeld "met PM"   zo terloops dat het klinkt alsof ik zou
moeten weten wat dat betekent :-)  (wat niet het geval is, sorry) Als
beginner leer ik graag bij, alvast bedankt.

groetjes,
-marc=

> mvg
> Gerard.
>
>
>
>
> 2010/11/29 Ben Laenen 
>>
>> Marc Portier wrote:
>> > Ben,
>> >
>> > bedankt voor het antwoord, logische opvolgvraag:
>> >
>> > Weten wat we (nu) weten, wordt het doorgaans aangeraden ons daarvan
>> > aan te trekken en door cosmetische veranderingen de rendering iets

Re: [OSM-talk-be] trunk crossroads and cyclerouting

[Gerard Vanderveken]

Hi,
I think the road is wrong classified.
http://www.openstreetmap.org/browse/way/8288162
It should be residential and part of the Celestijnenlaan and not trunk_link
http://www.openstreetmap.org/browse/way/72912809
http://www.openstreetmap.org/browse/way/3877191
Because that is what it is there: a crossing between the Celestijnenlaan 
and the trunk of Koning Boudewijnlaan.

http://www.openstreetmap.org/browse/way/16771612
http://www.openstreetmap.org/browse/way/17773075
http://www.openstreetmap.org/browse/way/23832344
http://www.openstreetmap.org/browse/way/73579618
As trunk_link it would link two trunks, which has no sense there.
Maybe add also the traffic signals on the two crosspoints
http://www.openstreetmap.org/browse/node/16571335
http://www.openstreetmap.org/browse/node/18232318
Regards,
Gerard


Klaas Gadeyne wrote:


Hi all,

At 
a small "junction way"
 exists between the
two parts of the Koning Boudewijnlaan (or Celestijnenlaan as you wish
:-)

This way is currently tagged as trunk_link
.  However, (at
least in Belgium) trunk roads are prohibited for bicycles.
Indeed, if you try to create the shortest cycle route from
Celestijnenlaan (South) to Celestijnenlaan (North), you end up with
.

So it seems like trunk_link ways are also "bicycles prohibited".  Does
anyone have a suggestion/thought on how to fix this?

- Changing trunk_link into primary_link seems weird (and only solves
the problem locally)
- Altering the "bicycles prohibited behaviour" of trunk_link sections
seems to be an option, but I don't know if this is the best thing to
do and whom to contact for that?
- Creating a separate cycleway might solve the problem locally (and
temporarily) but not in other places where the issue might exist.

Better suggestions welcome.

Thx

Klaas

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

 




___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] trunk crossroads and cyclerouting

[Klaas Gadeyne]

Hi all,

At 
a small "junction way"
 exists between the
two parts of the Koning Boudewijnlaan (or Celestijnenlaan as you wish
:-)

This way is currently tagged as trunk_link
.  However, (at
least in Belgium) trunk roads are prohibited for bicycles.
Indeed, if you try to create the shortest cycle route from
Celestijnenlaan (South) to Celestijnenlaan (North), you end up with
.

So it seems like trunk_link ways are also "bicycles prohibited".  Does
anyone have a suggestion/thought on how to fix this?

- Changing trunk_link into primary_link seems weird (and only solves
the problem locally)
- Altering the "bicycles prohibited behaviour" of trunk_link sections
seems to be an option, but I don't know if this is the best thing to
do and whom to contact for that?
- Creating a separate cycleway might solve the problem locally (and
temporarily) but not in other places where the issue might exist.

Better suggestions welcome.

Thx

Klaas

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be