[OSM-talk-be] layer probleempje

[Gerard Vanderveken]

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.
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.
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.
Naast de aflopende weg ligt er eigenlijk nog gedeeltelijk een derde weg 
die nog niet gemapt is.
De Parking ligt binnen de twee wegen.
http://www.openstreetmap.org/browse/way/86989968
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).
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.

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

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

mvg
Gerard.

>
>
>
> 2010/11/29 Ben Laenen <benlaenen at gmail.com <mailto:benlaenen at gmail.com>>
>
>     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
>     > vollediger/juister te krijgen
>
>     Nee, het motto dat daarbij hoort is steeds "don't tag for the
>     renderer"
>
>     Je kan het zeker mooi krijgen met mapnik, maar andere renders
>     hebben er
>     misschien geen probleem mee en die zou je dan ook veranderen.
>
>     Tag waar alles zich exact bevindt, dat is de enige juist manier.
>
>     Ben
>
>     _______________________________________________
>     Talk-be mailing list
>     Talk-be at openstreetmap.org <mailto:Talk-be at openstreetmap.org>
>     http://lists.openstreetmap.org/listinfo/talk-be
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Talk-be mailing list
>Talk-be at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-be
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20101203/09593043/attachment.htm>