date:20101006

Hallo,

Voor de fietsrouteplanner van Zuid-Nederland en de regio twente gaan wij 
een inventarisatieslag uitvoeren voor het fietsknopennetwerk.
Een groot gedeelte van het fietsknopennetwerk is al opgenomen in OSM, maar 
wij willen het compleet maken voor deze regio's.

Hoe gaan we dat aanpakken? Op basis van bestanden die we van de provincies 
aangeleverd hebben gekregen controlen we waar nog routes ontbreken of waar 
OSM afwijkt van deze bestanden.
In het geval van ontbrekende routes vullen we deze aan op basis van de 
omschrijving die op http://wiki.openstreetmap.org/wiki/Fietsroutes
In het geval van afwijkingen gaan we er vanuit dat wat in OSM zit correct 
is, maar controleren we dit waar mogelijk aan de hand van panoramafoto's.
Als een knooppunt op bijvoorbeeld een rotonde ligt worden alle 
aansluitingen van de rotonde van een knooppuntnummer voorzien, zodat een 
fietser altijd de knoop 'aanraakt' bij het passeren van de rotonde.
In feite is de hele rotonde onderdeel van het knooppunt.

Mochten er nog vragen of opmerkingen zijn dan horen we dit natuurlijk 
graag.

Met vriendelijke groet,

Francien Bouma-Blok
Goudappel Coffeng BV
i http://www.goudappel.nl

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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Stefan de Konink


On Wed, 6 Oct 2010, fbo...@goudappel.nl wrote:


Hoe gaan we dat aanpakken? Op basis van bestanden die we van de provincies
aangeleverd hebben gekregen controlen we waar nog routes ontbreken of waar
OSM afwijkt van deze bestanden.


Klinkt goed, zou het mogelijk zijn deze bestanden ook ergens neer te 
zetten zodat we deze kunnen mirroren?



Stefan

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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland enTwente

Deze bestanden mogen wij gebruiken voor de inventarisatie, maar ik weet 
niet of ik ze mag publiceren.
Als dit noodzakelijk is kan ik daar altijd naar informeren.
De bestanden zijn bovendien richtinggevend en kunnen in de praktijk anders 
tot uitvoering zijn gebracht, omdat de situatie ter plekke anders bleek te 
zijn.
Dit proberen we zo goed mogelijk te achterhalen op basis van 
panoramafoto's.
We zullen dan ook een source toevoegen met de bron, zodat OSM-gebruikers 
die ontdekken dat de route in werkelijkheid anders loopt deze makkelijk 
kunnen traceren en aanpassen.

Groeten Francien





Stefan de Konink ste...@konink.de 
Sent by: talk-nl-boun...@openstreetmap.org
10/06/2010 10:47 AM
Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org


To
OpenStreetMap NL discussion list talk-nl@openstreetmap.org
cc

Subject
Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en 
Twente






On Wed, 6 Oct 2010, fbo...@goudappel.nl wrote:

 Hoe gaan we dat aanpakken? Op basis van bestanden die we van de 
provincies
 aangeleverd hebben gekregen controlen we waar nog routes ontbreken of 
waar
 OSM afwijkt van deze bestanden.

Klinkt goed, zou het mogelijk zijn deze bestanden ook ergens neer te 
zetten zodat we deze kunnen mirroren?


Stefan

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



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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Foppe Benedictus

 Hallo

Op 06-10-10 10:18, fbo...@goudappel.nl schreef:


 Hallo,



 Voor de fietsrouteplanner van Zuid-Nederland en de regio
twente

 gaan wij een inventarisatieslag uitvoeren voor het

 fietsknopennetwerk. Een groot gedeelte van het
fietsknopennetwerk

 is al opgenomen in OSM, maar wij willen het compleet maken
voor

 deze regio's.
Ik kan voor Twente zeggen dat er nog heel veel ontbreekt.


 Hoe gaan we dat aanpakken? Op basis van bestanden die we
van de

 provincies aangeleverd hebben gekregen controlen we waar
nog

 routes ontbreken of waar OSM afwijkt van deze bestanden.
Volgens mij zijn er op dit moment niet heel veel mensen ook actief mee
bezig (gbakhuis in westelijk deel misschien wel). Het meeste werk ligt
ook buiten mijn/onze actieradius (Enschede als startpunt). Ik zou
zeggen plan een mooie herfsttocht door het mooie Twentse landschap :P
 In het geval van ontbrekende
routes vullen we deze aan op basis

 van de omschrijving die op

 http://wiki.openstreetmap.org/wiki/Fietsroutes In het geval
van

 afwijkingen gaan we er vanuit dat wat in OSM zit correct
is, maar

 controleren we dit waar mogelijk aan de hand van
panoramafoto's.

 Als een knooppunt op bijvoorbeeld een rotonde ligt worden
alle

 aansluitingen van de rotonde van een knooppuntnummer
voorzien,

 zodat een fietser altijd de knoop 'aanraakt' bij het
passeren van

 de rotonde. In feite is de hele rotonde onderdeel van het

 knooppunt.
Ik weet niet of dit een heel handige manier is gezien eventueel
hernummeren of ander ander onderhoud, dan moet je dus minimaal 4 nodes
veranderen, wat geheid fouten gaat opleveren.

Daarnaast dan de vraag aan openfietskaart of de render dan zo gemaakt
kan worden dat ze wel maar 1 knooppuntnummer tonen (binnen straal van
500m zelfde nummer combineren in het midden?).

In Twente zijn ook een aantal knooppunten die zonder rotonde hetzelfde
probleem hebben overigens. Bijvoorbeeld [1] bij knpt 17.

[1]
http://openfietskaart.nl/?zoom=15lat=52.2713lon=6.94293layers=BTFT
http://openfietskaart.nl/?zoom=16lat=52.27304lon=6.94388layers=BTFT

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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Foppe Benedictus


 Omdat de vorige poging een lelijke mail opleverde, poging 2

Op 06-10-10 10:18, fbo...@goudappel.nl schreef:

Hallo,

Voor de fietsrouteplanner van Zuid-Nederland en de regio twente gaan wij een
inventarisatieslag uitvoeren voor het fietsknopennetwerk.
Een groot gedeelte van het fietsknopennetwerk is al opgenomen in OSM, maar wij
willen het compleet maken voor deze regio's.

Ik kan voor Twente zeggen dat er nog heel veel ontbreekt.


Hoe gaan we dat aanpakken? Op basis van bestanden die we van de provincies
aangeleverd hebben gekregen controlen we waar nog routes ontbreken of waar OSM
afwijkt van deze bestanden.

Volgens mij zijn er op dit moment niet heel veel mensen ook actief mee bezig 
(gbakhuis in westelijk deel misschien wel). Het meeste werk ligt ook buiten 
mijn/onze actieradius (Enschede als startpunt). Ik zouzeggen plan een mooie 
herfsttocht door het mooie Twentse landschap :P


In het geval van ontbrekende routes vullen we deze aan op basis van de
omschrijving die op http://wiki.openstreetmap.org/wiki/Fietsroutes
In het geval van afwijkingen gaan we er vanuit dat wat in OSM zit correct is,
maar controleren we dit waar mogelijk aan de hand van panoramafoto's.
Als een knooppunt op bijvoorbeeld een rotonde ligt worden alle aansluitingen van
de rotonde van een knooppuntnummer voorzien, zodat een fietser altijd de knoop
'aanraakt' bij het passeren van de rotonde.
In feite is de hele rotonde onderdeel van het knooppunt.


Ik weet niet of dit een heel handige manier is gezien eventueel hernummeren of 
ander ander onderhoud, dan moet je dus minimaal 4 nodes veranderen, wat geheid 
fouten gaat opleveren.

Daarnaast dan de vraag aan openfietskaart of de render dan zo gemaakt kan 
worden dat ze wel maar 1 knooppuntnummer tonen (binnen straal van 500m zelfde 
nummer combineren in het midden?).

In Twente zijn ook een aantal knooppunten die zonder rotonde hetzelfde probleem 
hebben overigens. Bijvoorbeeld [1] bij knpt 17.

[1] 
http://openfietskaart.nl/?zoom=15lat=52.2713lon=6.94293layers=BTFT


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

Re: [OSM-talk-nl] Doorgetrokken middenstreep

2010-10-06 Per discussione Colin Smale


 Er is een topic gestart op het forum:

http://forum.openstreetmap.org/viewtopic.php?pid=109316

On 04/10/2010 07:58, Colin Smale wrote:
  Sinds kort bestaat de N201 tussen Vinkeveen en de A2 nu (in OSM) uit 
twee wegen met oneway=yes, alsof het gescheiden weghelften zouden 
zijn. Ik heb altijd begrepen dat alleen fysieke afscheidingen tellen 
(zie [1]), en die zijn er daar niet, alleen een doorgetrokken streep. 
Maar ik had me al veel eerder af zitten vragen of het een goed idee 
zou zijn om een doorgetrokken streep hetzelfde te behandelen als een 
fysieke afscheiding, bijvoorbeeld in het verlengde van op- en afritten 
van snelwegen. Waar eindigt de oprit (dus waar komen de motorway en de 
motorway_link bij elkaar)? Soms worden ze nog honderden meters voorbij 
het eind van de vangrail nog gescheiden gehouden door een 
doorgetrokken streep waar je niet overheen mag. Hoe zouden we om 
moeten gaan met een doorgetrokken middenstreep naast een onderbroken 
streep, waarbij je er in de ene richting niet overheen mag en in de 
andere richting wel?


Colin

[1] 
http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways 




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



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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Itserik


 Op 6-10-2010 10:18, fbo...@goudappel.nl schreef:


Als een knooppunt op bijvoorbeeld een rotonde ligt worden alle 
aansluitingen van de rotonde van een knooppuntnummer voorzien, zodat 
een fietser altijd de knoop 'aanraakt' bij het passeren van de rotonde.

In feite is de hele rotonde onderdeel van het knooppunt.
Over het algemeen staat er een info bord op het knooppunt. Zelf voorzie 
ik de node (aan een weg) die het dichtst bij dit punt ligt van een 
knoopuntnummer. Alle wegen die vanaf die node naar de andere knooppunten 
vertrekken kunnen elkaar dus overlappen.


Als je alle nodes van zo'n rotondeknooppunt als knooppunt maakt. Dan 
zouden deze nodes ook aan de netwerkrelatie moeten worden toegevoegd. 
Dit lijkt me niet helemaal wenselijk.


Ik zou zeggen kijk eens rond op andere rotondes en kijk hoe het daar 
gedaan is.


gr Erik
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Ne derland en Twente

2010-10-06 Per discussione Maarten Deen

On Wed, 06 Oct 2010 12:19:16 +0200, Itserik e...@itserik.nl wrote:
 Op 6-10-2010 10:18, fbo...@goudappel.nl [1] schreef:  
  Als een knooppunt op bijvoorbeeld een rotonde ligt worden alle
 aansluitingen van de rotonde van een knooppuntnummer voorzien, zodat
 een fietser altijd de knoop 'aanraakt' bij het passeren van de
 rotonde.
  In feite is de hele rotonde onderdeel van het knooppunt.
   Over het algemeen staat er een info bord op het knooppunt. Zelf
 voorzie ik de node (aan een weg) die het dichtst bij dit punt ligt van
 een knoopuntnummer. Alle wegen die vanaf die node naar de andere
 knooppunten vertrekken kunnen elkaar dus overlappen.
 
  Als je alle nodes van zo'n rotondeknooppunt als knooppunt maakt. Dan
 zouden deze nodes ook aan de netwerkrelatie moeten worden toegevoegd.
 Dit lijkt me niet helemaal wenselijk.

Daar ben ik het mee eens. Ik probeer de node van het knooppunt ook daar
te zetten waar het bord staat, maar wel als onderdeel van een way. Bij
rotondes heb je wel eens buitenliggende fietspaden, dan komt de node
meestal op een splitsing van de fietspaden.

Als je wegen hebt die met gescheiden rijbanen bij een rotonde aankomen,
dan zou je daar ook tot 8 nodes neer moeten zetten?

Zie bijvoorbeeld
http://openfietskaart.nl/?zoom=17lat=51.44945lon=5.95208layers=BTFT.
Er is daar een vrijliggend fietspad met het knooppuntbord tussen de
zuidelijke en oostelijke weg in. Het lijkt me ook voor de rendering van
de fietskaart niet bevorderlijk om daar meer nodes neer te leggen.

Maarten


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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Lennard


On 6-10-2010 11:16, Foppe Benedictus wrote:


Daarnaast dan de vraag aan openfietskaart of de render dan zo gemaakt
kan worden dat ze wel maar 1 knooppuntnummer tonen (binnen straal van
500m zelfde nummer combineren in het midden?).


500 m is erg ver. Ik zat zelf te denken aan meer dan 2 keer hetzelfde 
nummer binnen 100-150 meter (afh van zoom). Daar zou je dan het 
middelpunt van kunnen pakken, met evt een licht anders uitziend symbool 
om aan te geven dat het niet de werkelijke locatie is.



In Twente zijn ook een aantal knooppunten die zonder rotonde hetzelfde
probleem hebben overigens. Bijvoorbeeld [1] bij knpt 17.


Als er 2 nabije punten zijn met hetzelfde nummer, zou ik ze gewoon zo 
laten staan op de kaart. Dat bezwaart niet zoveel als bij een rotonde 
waar je er meer dan 2 tegenkomt.



--
Lennard

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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

2010-10-06 Per discussione Lennard


On 6-10-2010 12:30, Maarten Deen wrote:


Er is daar een vrijliggend fietspad met het knooppuntbord tussen de
zuidelijke en oostelijke weg in. Het lijkt me ook voor de rendering van
de fietskaart niet bevorderlijk om daar meer nodes neer te leggen.


Het gaat niet puur om de rendering, en dat kunnen we nog sturen, mits de 
onderliggende data correct is.


Het punt is dat een router het ook nog goed snapt, en die maakt het vast 
niet uit dat er meer keren hetzelfde nummer voorkomt, als er maar een te 
volgen weg is vast te stellen tussen de punten.


--
Lennard

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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en?Twente

2010-10-06 Per discussione Vincent Zweije

On Wed, Oct 06, 2010 at 12:30:32PM +0200, Maarten Deen wrote:

||  On Wed, 06 Oct 2010 12:19:16 +0200, Itserik e...@itserik.nl wrote:
||   Op 6-10-2010 10:18, fbo...@goudappel.nl [1] schreef:  
||Als een knooppunt op bijvoorbeeld een rotonde ligt worden alle
||   aansluitingen van de rotonde van een knooppuntnummer voorzien, zodat
||   een fietser altijd de knoop 'aanraakt' bij het passeren van de
||   rotonde.
||In feite is de hele rotonde onderdeel van het knooppunt.
|| Over het algemeen staat er een info bord op het knooppunt. Zelf
||   voorzie ik de node (aan een weg) die het dichtst bij dit punt ligt van
||   een knoopuntnummer. Alle wegen die vanaf die node naar de andere
||   knooppunten vertrekken kunnen elkaar dus overlappen.
||   
||Als je alle nodes van zo'n rotondeknooppunt als knooppunt maakt. Dan
||   zouden deze nodes ook aan de netwerkrelatie moeten worden toegevoegd.
||   Dit lijkt me niet helemaal wenselijk.
||  
||  Daar ben ik het mee eens. Ik probeer de node van het knooppunt ook daar
||  te zetten waar het bord staat, maar wel als onderdeel van een way. Bij
||  rotondes heb je wel eens buitenliggende fietspaden, dan komt de node
||  meestal op een splitsing van de fietspaden.

Ook ik plaats doorgaans 1 node in de route op een punt zo dicht mogelijk
bij de feitelijke plaats van het knooppuntbord.

Maar even een stapje terug: de plaats van het bord en de routering zijn
twee verschillende dingen.

Voor routering wil je, lijkt mij, eigenlijk alle punten markeren waar
een routesplitsing bestaat. Bij een enkel knooppunt, bijvoorbeeld op een
rotonde waar vier routes samenkomen, zijn er vier tot acht van zulke
punten. Deze punten zijn dus interessant voor routering, maar is er
doorgaans maar 1 knooppuntbord.

Dus eigenlijk zouden er twee soorten tags moeten zijn: 1 om het bord
aan te geven, en 1 om de routering te ondersteunen.

De huidige praktijk is niet perfect...  Vincent.
-- 
Vincent Zweije zwe...@xs4all.nl| If you're flamed in a group you
http://www.xs4all.nl/~zweije/  | don't read, does anybody get burnt?
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en Twente

Bedankt voor deze reacties,

Ons idee is nu dat we als de afstand tussen de locaties minder dan 100 
meter is, dat we dan maar 1 knoop maken. 
Als de locaties veel verder uit elkaar liggen wordt er een dubbel 
knoopnummer gemaakt.
Dit gebeurt dan op slechts enkele plaatsen en als ik het goed begrijp van 
Lennard is dat dus geen probleem?

Groeten Francien




Lennard l...@xs4all.nl 
Sent by: talk-nl-boun...@openstreetmap.org
10/06/2010 02:01 PM
Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org


To
talk-nl@openstreetmap.org
cc

Subject
Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en 
Twente






On 6-10-2010 12:30, Maarten Deen wrote:

 Er is daar een vrijliggend fietspad met het knooppuntbord tussen de
 zuidelijke en oostelijke weg in. Het lijkt me ook voor de rendering van
 de fietskaart niet bevorderlijk om daar meer nodes neer te leggen.

Het gaat niet puur om de rendering, en dat kunnen we nog sturen, mits de 
onderliggende data correct is.

Het punt is dat een router het ook nog goed snapt, en die maakt het vast 
niet uit dat er meer keren hetzelfde nummer voorkomt, als er maar een te 
volgen weg is vast te stellen tussen de punten.

-- 
Lennard

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



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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland enTwente

2010-10-06 Per discussione robert


panoramafoto's = Streetview?

Groet Robert


Citeren fbo...@goudappel.nl:


Deze bestanden mogen wij gebruiken voor de inventarisatie, maar ik weet
niet of ik ze mag publiceren.
Als dit noodzakelijk is kan ik daar altijd naar informeren.
De bestanden zijn bovendien richtinggevend en kunnen in de praktijk anders
tot uitvoering zijn gebracht, omdat de situatie ter plekke anders bleek te
zijn.
Dit proberen we zo goed mogelijk te achterhalen op basis van
panoramafoto's.
We zullen dan ook een source toevoegen met de bron, zodat OSM-gebruikers
die ontdekken dat de route in werkelijkheid anders loopt deze makkelijk
kunnen traceren en aanpassen.

Groeten Francien





Stefan de Konink ste...@konink.de
Sent by: talk-nl-boun...@openstreetmap.org
10/06/2010 10:47 AM
Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org


To
OpenStreetMap NL discussion list talk-nl@openstreetmap.org
cc

Subject
Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en
Twente






On Wed, 6 Oct 2010, fbo...@goudappel.nl wrote:


Hoe gaan we dat aanpakken? Op basis van bestanden die we van de

provincies

aangeleverd hebben gekregen controlen we waar nog routes ontbreken of

waar

OSM afwijkt van deze bestanden.


Klinkt goed, zou het mogelijk zijn deze bestanden ook ergens neer te
zetten zodat we deze kunnen mirroren?


Stefan

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








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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland enTwente

2010-10-06 Per discussione Stefan de Konink


Cyclomedia

Stefan

Op 6 okt 2010 om 15:18 heeft rob...@elsenaar.info het volgende  
geschreven:\



panoramafoto's = Streetview?

Groet Robert


Citeren fbo...@goudappel.nl:

Deze bestanden mogen wij gebruiken voor de inventarisatie, maar ik  
weet

niet of ik ze mag publiceren.
Als dit noodzakelijk is kan ik daar altijd naar informeren.
De bestanden zijn bovendien richtinggevend en kunnen in de praktijk  
anders
tot uitvoering zijn gebracht, omdat de situatie ter plekke anders  
bleek te

zijn.
Dit proberen we zo goed mogelijk te achterhalen op basis van
panoramafoto's.
We zullen dan ook een source toevoegen met de bron, zodat OSM- 
gebruikers
die ontdekken dat de route in werkelijkheid anders loopt deze  
makkelijk

kunnen traceren en aanpassen.

Groeten Francien





Stefan de Konink ste...@konink.de
Sent by: talk-nl-boun...@openstreetmap.org
10/06/2010 10:47 AM
Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org


To
OpenStreetMap NL discussion list talk-nl@openstreetmap.org
cc

Subject
Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en
Twente






On Wed, 6 Oct 2010, fbo...@goudappel.nl wrote:


Hoe gaan we dat aanpakken? Op basis van bestanden die we van de

provincies
aangeleverd hebben gekregen controlen we waar nog routes ontbreken  
of

waar

OSM afwijkt van deze bestanden.


Klinkt goed, zou het mogelijk zijn deze bestanden ook ergens neer te
zetten zodat we deze kunnen mirroren?


Stefan

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








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


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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerkZuid-NederlandenTwente

2010-10-06 Per discussione ce-test, qualified testing bv - Gert Gremmen

inderdaad




Stefan de Konink ste...@konink.de 
Sent by: talk-nl-boun...@openstreetmap.org
10/06/2010 03:36 PM
Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org


To
OpenStreetMap NL discussion list talk-nl@openstreetmap.org
cc
talk-nl@openstreetmap.org talk-nl@openstreetmap.org
Subject
Re: [OSM-talk-nl] inventarisatie fietsknopennetwerkZuid-Nederland enTwente






Cyclomedia

Stefan

Op 6 okt 2010 om 15:18 heeft rob...@elsenaar.info het volgende 
geschreven:\

 panoramafoto's = Streetview?

 Groet Robert


 Citeren fbo...@goudappel.nl:

 Deze bestanden mogen wij gebruiken voor de inventarisatie, maar ik 
 weet
 niet of ik ze mag publiceren.
 Als dit noodzakelijk is kan ik daar altijd naar informeren.
 De bestanden zijn bovendien richtinggevend en kunnen in de praktijk 
 anders
 tot uitvoering zijn gebracht, omdat de situatie ter plekke anders 
 bleek te
 zijn.
 Dit proberen we zo goed mogelijk te achterhalen op basis van
 panoramafoto's.
 We zullen dan ook een source toevoegen met de bron, zodat OSM- 
 gebruikers
 die ontdekken dat de route in werkelijkheid anders loopt deze 
 makkelijk
 kunnen traceren en aanpassen.

 Groeten Francien





 Stefan de Konink ste...@konink.de
 Sent by: talk-nl-boun...@openstreetmap.org
 10/06/2010 10:47 AM
 Please respond to
 OpenStreetMap NL discussion list talk-nl@openstreetmap.org


 To
 OpenStreetMap NL discussion list talk-nl@openstreetmap.org
 cc

 Subject
 Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en
 Twente






 On Wed, 6 Oct 2010, fbo...@goudappel.nl wrote:

 Hoe gaan we dat aanpakken? Op basis van bestanden die we van de
 provincies
 aangeleverd hebben gekregen controlen we waar nog routes ontbreken 
 of
 waar
 OSM afwijkt van deze bestanden.

 Klinkt goed, zou het mogelijk zijn deze bestanden ook ergens neer te
 zetten zodat we deze kunnen mirroren?


 Stefan

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







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

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



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

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederlanden Twente

Ik vind dat we maar een (1) knooppunt moeten plaatsen.

Waarom:

 

-  Er is er fysiek  maar een (1) knooppuntbord aanwezig en de
exacte plaats daarvan is soms echt belangrijk voor de fietsers.

-  Als we kaarten printen (denk ook aan derden en afnemers)
lopen we steeds opnieuw het risico van een kakofonie van knooppunten

-  We moeten de routers leren dat op kruispunten en rotondes
alle overbodige routing naar de exacte plaats van het knooppunt

kan worden verwijderd. Als je goed nadenkt is dat eenvoudig, bijna alle
gevallen kenmerken die stukjes zich door routes in 2 richtingen op
hetzelfde way stuk.

-  Op rotondes die niet als rotonde zijn getagged  moet de
router herkennen  dat het knooppunt op een cirkel van eenrichting paden
ligt en dat deze niet het knooppunt hoeft te raken om ok te zijn.

 

Als we de knooppunten niet gebruiken om de exacte plaats van een
routebord aan te duiden, dan moet voor het routebord  een nieuwe tag
bedacht worden

en moet de huidige rcn-tagging onzichtbaar worden. Dan is het geen
bezwaar als er -tig knooppunten op een kruispunt liggen . Alleen de
controle

en statistiek met de PC worden dan wat lastiger.

 

Omdat de situatie nu het meest op de eerste situatie lijkt , is het
misschien het beste om de routers aan te passen.

Soortgelijke situaties komen nl ook op ander plekken voor.

 

Tik maar eens in op google dat je  van Rotterdam naar Amsterdam wilt
rijden via

Utrecht. De kans is groot dat je door het centrum wordt geleidt, terwijl
de router moet snappen dat je alleen  maar niet via den haag wilt.

Ook daar is sprake van een route utrecht in en weer uit= dubbele route
heen/terug op hetzelfde wegvak of tenminste

uitkomende de hetzelfde autoweg, en een wegdeel dat geschrapt kan
wordne.

 

In de huidige routers (ook bij google) moet je een tussenpunt klikken op
de autoweg  als je via utrecht wilt en owee als de router

denkt dat dat op de tegengestelde richting ligt.

 

Gert

 

 

 

 

 

 

Van: talk-nl-boun...@openstreetmap.org
[mailto:talk-nl-boun...@openstreetmap.org] Namens fbo...@goudappel.nl
Verzonden: woensdag 6 oktober 2010 14:33
Aan: OpenStreetMap NL discussion list
Onderwerp: Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk
Zuid-Nederlanden Twente

 


Bedankt voor deze reacties,

Ons idee is nu dat we als de afstand tussen de locaties minder dan 100
meter is, dat we dan maar 1 knoop maken. 
Als de locaties veel verder uit elkaar liggen wordt er een dubbel
knoopnummer gemaakt.
Dit gebeurt dan op slechts enkele plaatsen en als ik het goed begrijp
van Lennard is dat dus geen probleem?

Groeten Francien




Lennard l...@xs4all.nl
Sent by: talk-nl-boun...@openstreetmap.org

10/06/2010 02:01 PM

Please respond to
OpenStreetMap NL discussion list talk-nl@openstreetmap.org

To

talk-nl@openstreetmap.org

cc


Subject

Re: [OSM-talk-nl] inventarisatie fietsknopennetwerk Zuid-Nederland en
Twente

 






On 6-10-2010 12:30, Maarten Deen wrote:

 Er is daar een vrijliggend fietspad met het knooppuntbord tussen de
 zuidelijke en oostelijke weg in. Het lijkt me ook voor de rendering
van
 de fietskaart niet bevorderlijk om daar meer nodes neer te leggen.

Het gaat niet puur om de rendering, en dat kunnen we nog sturen, mits de

onderliggende data correct is.

Het punt is dat een router het ook nog goed snapt, en die maakt het vast

niet uit dat er meer keren hetzelfde nummer voorkomt, als er maar een te

volgen weg is vast te stellen tussen de punten.

-- 
Lennard

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



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

Re: [OSM-talk-nl] Doorgetrokken middenstreep

2010-10-06 Per discussione ce-test, qualified testing bv - Gert Gremmen

een beetje off-topic.

Waneer is een doorgetrokken streep wettelijk doorgetrokken. ?
Ik zie steeds vaker wegen waar die zogenaamd doorgetrokken streep
om de zoveel meter kleine onderbrekingen heeft in de ordergrootte
van 10 cm. Of is de wel-onderbroken streep goed gedefinieerd
en kunnen we daaruit afleiden wanneer een streep ononderbroken is.
Het is een beetje komma-dingesen maar juridisch wel belangrijk.

Gert



-Oorspronkelijk bericht-
Van: talk-nl-boun...@openstreetmap.org
[mailto:talk-nl-boun...@openstreetmap.org] Namens Colin Smale
Verzonden: woensdag 6 oktober 2010 11:51
Aan: talk-nl@openstreetmap.org
Onderwerp: Re: [OSM-talk-nl] Doorgetrokken middenstreep

  Er is een topic gestart op het forum:

http://forum.openstreetmap.org/viewtopic.php?pid=109316

On 04/10/2010 07:58, Colin Smale wrote:
   Sinds kort bestaat de N201 tussen Vinkeveen en de A2 nu (in OSM) uit

 twee wegen met oneway=yes, alsof het gescheiden weghelften zouden 
 zijn. Ik heb altijd begrepen dat alleen fysieke afscheidingen tellen 
 (zie [1]), en die zijn er daar niet, alleen een doorgetrokken streep. 
 Maar ik had me al veel eerder af zitten vragen of het een goed idee 
 zou zijn om een doorgetrokken streep hetzelfde te behandelen als een 
 fysieke afscheiding, bijvoorbeeld in het verlengde van op- en afritten

 van snelwegen. Waar eindigt de oprit (dus waar komen de motorway en de

 motorway_link bij elkaar)? Soms worden ze nog honderden meters voorbij

 het eind van de vangrail nog gescheiden gehouden door een 
 doorgetrokken streep waar je niet overheen mag. Hoe zouden we om 
 moeten gaan met een doorgetrokken middenstreep naast een onderbroken 
 streep, waarbij je er in de ene richting niet overheen mag en in de 
 andere richting wel?

 Colin

 [1] 

http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Div
ided_highways 



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


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

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

Re: [OSM-talk-nl] Doorgetrokken middenstreep

2010-10-06 Per discussione Colin Smale


 On 06/10/2010 21:29, ce-test, qualified testing bv - Gert Gremmen wrote:

een beetje off-topic.

Waneer is een doorgetrokken streep wettelijk doorgetrokken. ?
Ik zie steeds vaker wegen waar die zogenaamd doorgetrokken streep
om de zoveel meter kleine onderbrekingen heeft in de ordergrootte
van 10 cm. Of is de wel-onderbroken streep goed gedefinieerd
en kunnen we daaruit afleiden wanneer een streep ononderbroken is.
Het is een beetje komma-dingesen maar juridisch wel belangrijk.

Die schijnen voor de afwatering te zijn. De strepen hebben een bepaalde 
dikte en zonder de kleine onderbrekinkjes zouden ze een plas water 
achterhouden.


http://forum.infopolitie.nl/viewtopic.php?f=69t=29289 
http://forum.infopolitie.nl/viewtopic.php?f=69t=29289



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

Re: [OSM-talk-nl] Doorgetrokken middenstreep

2010-10-06 Per discussione Lennard


On 6-10-2010 21:29, ce-test, qualified testing bv - Gert Gremmen wrote:


Waneer is een doorgetrokken streep wettelijk doorgetrokken. ?
Ik zie steeds vaker wegen waar die zogenaamd doorgetrokken streep
om de zoveel meter kleine onderbrekingen heeft in de ordergrootte


Die zijn voor afwatering. Als een streep ononderbroken *oogt*, bij 
normaal gebruik van en bij normale snelheden op die weg, dan is die 
ononderbroken.



--
Lennard

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

Re: [OSM-talk-nl] Doorgetrokken middenstreep

2010-10-06 Per discussione ce-test, qualified testing bv - Gert Gremmen

Voor mij *oogt* ie onderbroken.
Mag ik dan inhalen ?

Gert

-Oorspronkelijk bericht-
Van: talk-nl-boun...@openstreetmap.org
[mailto:talk-nl-boun...@openstreetmap.org] Namens Lennard
Verzonden: woensdag 6 oktober 2010 21:55
Aan: talk-nl@openstreetmap.org
Onderwerp: Re: [OSM-talk-nl] Doorgetrokken middenstreep

On 6-10-2010 21:29, ce-test, qualified testing bv - Gert Gremmen wrote:

 Waneer is een doorgetrokken streep wettelijk doorgetrokken. ?
 Ik zie steeds vaker wegen waar die zogenaamd doorgetrokken streep
 om de zoveel meter kleine onderbrekingen heeft in de ordergrootte

Die zijn voor afwatering. Als een streep ononderbroken *oogt*, bij 
normaal gebruik van en bij normale snelheden op die weg, dan is die 
ononderbroken.


-- 
Lennard

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

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

[talk-au] World's biggest book...

2010-10-06 Per discussione John Smith

The world's biggest book fair in Frankfurt is used to seeing some big
book launches, but none came larger than a six-by-nine-foot (1.82 by
2.74 metres) atlas unveiled on Wednesday.

http://www.abc.net.au/news/stories/2010/10/06/3031388.htm

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

Re: [Talk-de] Das neue Taginfo

2010-10-06 Per discussione Claudius


Am 05.10.2010 22:46, Jochen Topf:

On Tue, Oct 05, 2010 at 10:07:14PM +0200, Claudius wrote:

Ich hab die Statistik allerdings erst nicht verstanden, da ich dein
Leerzeichen nicht als Tausender-Trennzeichen interpretierte. Habe mich
lange gewundert, was denn die drei Zahlen 17 288 071 für
highway=residential bedeuteten und mutmasste schon verschiedene Werte
für Wiki, Datenbank und andere Orte. Zudem sehe ich statt dem
Leerzeichen unter Opera 10.62 in Windows7 ein Kästchen. Im Quelltext
sieht es aber wie ein völlig normales Leerzeichen aus.


Das ist ein halb-breites Leerzeichen (thinsp;). Du bist jetzt schon der
zweite, der das mit Opera unter Windows nicht angezeigt bekommt. Unter IE,
FF, Chrome und Opera 9 unter Linux tut es. Also das würde ich mal als Bug
bei Opera einstufen.


Offenbar tritt es nur beim Rendering von thinsp; im Verdana-Font auf. 
Mit Arial wird es ein schönes halblanges Leerzeichen: 
http://my.opera.com/community/forums/topic.dml?id=246660


Ich habe es als Bug an Opera weitergeleitet.

Claudius



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

Re: [Talk-de] öffentl. Schließfächer

Am Dienstag 05 Oktober 2010, 22:29:30 schrieb Johannes Huesing:
 olvagor o...@terbrueggen.net [Mon, Oct 04, 2010 at 10:52:25AM CEST]:
 [...]
 
  dimensions=20x50x50 (Breite x Höhe x Tiefe in cm)
 
 Da wäre ich eher für Meter, analog zu maxwidth. Das x sieht mir auch eher
 wie ein Notbehelf aus.

einerseits ja, da man einen einheitliche Masseinheit hat.
andererseits nein, denn die Groesse von Schliessfaechern wird sich eher selten 
im Meterbereich bewegen. Ausserdem ist eine Angabe von 0.20x0.50x0.50 weniger 
gut leserlich.


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schiessstand Schweiz


Morgen Ulf,

Du immer mit Deiner drastischen Ausdrucksweise ;-)

Und nein: ich bin kein Militarist - eher Pazifist.
Also habe ich das mit dem sport=shooting mal eingetragen
(obwohl - ich glaube, die meisten Schweizer würden diesem Sport nicht 
so fröhnen, wenn es für sie nicht militärische Pflicht wäre)...



Die Anlage besteht aus:
- Schützenhaus (mit Parkplatz)
- Wall mit Scheiben etc.
- Schussrichtung vom Haus zu den Scheiben

┌─┐
│ |
│ | ─ │
│ |
└─┘


Habe jetzt mal ein eigenes Schema ausprobiert:
http://www.openstreetmap.org/?lat=47.524031lon=8.431179zoom=18

Die Schussbahn ist allerdings nur bei Kurzdistanz (50m) eine Seilbahn.
Bei 300m erfolgt die Anzeige elektronisch (power=line?),
oder visuell (aber dafür kenne ich kein OSM-Attribut).


Da ist kein Sessellift, also trage da auch keinen ein.


Ja, das war keine gute Idee - Osmarender malt neben die Linie einen auf 
dem Kopf stehenden Zweiersessel mit zwei kopfüber darin hängenden 
Touristen :-(

Vielleicht einfach Seilbahn=yes? Oder Schiessbahn=yes?

Als Datensammler hat man zwei Möglichkeiten:
a) man bedient sich aus dem OSM-Portfolio und wählt ungefähr passendes
b) man erfindet etwas Neues

Da ich kein Schiessstandspezialist bin (obwohl auch ich solche 
regelmässig benutzen musste), und da es aus der Community bisher keine 
wirklich brauchbaren Lösungen gab, habe ich mich für a) entschieden.

Aber das ist natürlich jederzeit verbesserbar :-)

Ist insgesamt ein etwas spezieller Fall diese offenen Schiessanlagen.
Bei einigen (Kurzdistanz) sieht man wirklich eine Seilbahn (sogar 
mehrere nebeneinander): da werden die Schiesstafeln hin und her 
gefahren, damit der Schütze nach dem Schuss genau prüfen kann wie er 
getroffen hat.
Bei Langdistanz sieht man oft gar nichts (aber wenn man nicht aufpasst 
kann es tödlich sein). Da ist erst mal nur eine Wiese, ein Acker, ein 
Weinberg. Vielleicht ein querender Weg, vielleicht weidende Kühe. 
Ansonsten nichts, was auf die Schussbahn hinweist.
Nur am Samstagmorgen, wenn die Männer ihre Treffsicherheit unter Beweis 
stellen müssen, dann wird über den Weg eine Leine mit Schild gehängt und 
das Vieh wird woanders hin gestellt.
Die Schützen schiessen im Schützenhaus. Ihre Kumpels verkriechen sich 
300m entfernt in einem Graben vor den Schiessscheiben und zeigen mit 
einer langen Kelle die Position des Treffers. Meist führt ein kleiner 
Weg zum Scheibenstand. Bei sehr modernen Anlagen erfolgt die Messung des 
Treffers an der Scheibe und die Anzeige im Schützenhaus elektronisch 
(Datenkabel ist meist verbuddelt).

Die Ziellinie muss übrigens immer mindestens 1m über Boden sein.
Vielleicht ein layer=-1?
Werden befahrene Strassen überschossen, so sind diese ab Strassenniveau
um mindestens 4,5m durch Tiefblenden abzudecken.
Das wäre dann barrier=wall?

Auch mit dem Scheibenstand bin ich noch nicht zufrieden:
Meist ist da ein aufgeschütteter Erdwall als Kugelfang (für alle die 
nicht so sicher treffen). Davor stehen die Scheissscheiben. Vor den 
Schiessscheiben ist ein Graben, in dem die Männer stehen/sitzen 
(amenity=bench?), meist überdacht (shelter=yes?), und einem 
(internen) Telefon zum Schützenhaus.



Ich hätte mehr von dir erwartet ...


Man tut was man kann :-)
Vielleicht hast Du ja gute Ideen?

Gruss, Markus

PS: gibt es eigentlich im Wiki oder so eine 
Neuer-tag-Vorschlagsliste-für-Renderer? Also sowas wie aminity (oder 
man_made?) = Schusslinie und der Renderer zeichnet dann einen 
rötlichen Pfeil?


Eine Alternative wäre, Zone 1 als temporäre Sperrfläche einzutragen.
Aber da habe ich auch nichts wirklich passendes gefunden.
(braucht man eigentlich noch das area=yes - oder kann man dem Renderer 
in der Regeln sagen, dass es eine Fläche ist?)

Vielleicht noch access=on_demand?

Habe jetzt mal Gefahrenzone 1 und Gefahrenzon 2 eingetragen.

Bei den Zonen 3, 4 und 5 verstehe ich den Text der Verordnung nicht so 
richtig...


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

Re: [Talk-de] Schiessstand Schweiz


Hallo Rolf,


Schießbahn ist die Einrichtung auf der geschossen wird.
Schußbahn ist die Bahn auf der die Kugel oder das Geschoss fliegt.


Ja, so kenne ich es auch.

Bei einer Open-Air-Schiessbahn (wie in der Schweiz üblich) sieht man 
aber oft nur das Schützenhaus und den Scheibenstand.
Das dazwischen ist unsichtbar - aber endgültig fühlbar (wenn man sich 
zur Unzeit dort hin verirrt). Eine Einrichtung ist da aber nicht.

In der Kartografie wird das Dazwischen als Pfeil dargestellt.

Schiessbahn ist also auch nicht so genau passend...
Schussbahn meint genaugenommen: Hauptschussbahn (es gibt ja immer 
auch Fehlschüsse: siehe Sicherheitszone 2..5).
Und genaugenommen müsste man je nach Anzahl der einzelnen Schiessstände 
mehrere Hauptschussbahnen einzeichnen (oder die eine mit lane=# ergänzen).
Aber ich mag hier nicht auch noch die Diskussion Linienbündel vs. 
lanes führen - das erschine mir oversized...


Gruss, Markus

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

[Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Florian Lohoff


Hi,
ich habe vorgestern mal versucht mit der All in One auf einem Nuevi 205 
zum Flughafen Paderborn Lippstadt zu navigieren. D.h. POI Suche, Verkehr
Flugplaetze. Alles drin d.h. die ganzen Sportflughaefen aber nicht Paderborn
Lippstadt.

Ich habe mir  gerade mal die Daten angesehen.

Sportflughafen Paderborn-Haxterberg 
Punkt mit 
amenity=airport
name=Paderborn-Haxterberg
http://www.openstreetmap.org/browse/node/739036316

Flaeche mit
aeroway=aerodrome
name=Paderborn-Haxterberg
http://www.openstreetmap.org/browse/way/26318807

Punkt mit
aeroway=aerodrom
name=Paderborn-Haxterberg
http://www.openstreetmap.org/browse/node/223644057

Verkehrsflughafen Paderborn-Lippstadt
Flaeche mit
aeroway=aerodrom
name=Paderborn-Lippstadt
http://www.openstreetmap.org/browse/way/19752503

Also irgendwie finde ich das reichlich inkonsistent. Dazu kommt das Haxterberg
schoen 2 Flugzeuge gemalt bekommt, Paderborn-Lippstadt aber keines. (Wird sich
verflogen haben).

Das mit dem Punkt statt Flaeche auswerten finde ich eigentlich viel pfiffiger 
weil
eben es auch durchaus mal Straßen geben koennte die am Flughafen auf der 
falschen
Seite vorbeigehen. D.h. exakt die Position des Terminals mit einem Node zu 
markieren
ist sicherlich pfiffig (Ich meine mein Festeinbau kennt bei den großen 
Flughaefen sogar
die unterschiedlichen Terminals).

Aber was wird in der All in One ausgewertet? amenity=airport oder 
aeroway=aerodrome? Punkt
oder Flaeche? Und was waere im Tagging richtig?

Flo
-- 
Florian Lohoff f...@zz.de
 Professionell gesehen bin ich zu haben 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Sven Geggus

Florian Lohoff f...@zz.de wrote:

 Aber was wird in der All in One ausgewertet? amenity=airport oder
 aeroway=aerodrome? Punkt oder Flaeche? Und was waere im Tagging richtig?

$ git clone git://github.com/aiomaster/aiostyles.git 
$ cd aiostyles/basemap_style/
$ grep airport *
points:aeroway=airport [0x5900 resolution 23]
points:#sport=airport [0x2d0b resolution 14]
$ grep aerodrome *
points:aeroway=aerodrome [0x2f04 resolution 23]

Offensichtlich also nur die Punkte.

Gruss

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/me is gig...@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Schiessstand Schweiz


 On 06.10.2010 09:19, Markus wrote:

Die Schussbahn ist allerdings nur bei Kurzdistanz (50m) eine Seilbahn.
Bei 300m erfolgt die Anzeige elektronisch (power=line?),
oder visuell (aber dafür kenne ich kein OSM-Attribut).


Da ist kein Sessellift, also trage da auch keinen ein.


Ja, das war keine gute Idee - Osmarender malt neben die Linie einen 
auf dem Kopf stehenden Zweiersessel mit zwei kopfüber darin hängenden 
Touristen :-(

BITTE!!!
Osmarender ist Osmarender, nicht die Datenbank.
Selbst wenn Osmarender keinen Sessel dranmalen würde: Was Du da 
einzeichnen willst, ist keine Seilbahn im Sinne eines Sessellifts - und 
genau das ist mit dem Tag gemeint.



Vielleicht einfach Seilbahn=yes? Oder Schiessbahn=yes?

Als Datensammler hat man zwei Möglichkeiten:
a) man bedient sich aus dem OSM-Portfolio und wählt ungefähr passendes

richtig - aber bitte nichts, was sprachlich ungefähr passt.
Es geht nicht um Sprachwissenschaften, sondern um eine Ontologie, ein 
Schema, das die Fakten eindeutig beschreibt.

b) man erfindet etwas Neues

Da ich kein Schiessstandspezialist bin (obwohl auch ich solche 
regelmässig benutzen musste), und da es aus der Community bisher keine 
wirklich brauchbaren Lösungen gab, habe ich mich für a) entschieden.

...aber nicht richtig angewandt: Seilbahn passt eben nicht.
Was besser passt weiß ich nicht, da sollte man sich mit englisch 
muttersprachlichen Schießsport-Fachleuten absprechen, Seilbahn 
jedenfalls passt nicht.

Aber das ist natürlich jederzeit verbesserbar :-)

Nein, ist es nicht.
Du mischt hier ein bestehendes Attribut für Sessellifte mit 
Rückhol-Mechanismen für Schießscheiben.
Solange du das genau einmal machst, hast Du recht, ist es verbesserbar. 
Üblicherweise übernehmen andere aber solche Schemata,
und was dann passiert, kannst Du in der Diskussion um Bäume 
(natural=tree) nachlesen,
das wieder auseinanderzudröseln ist nämlich nicht möglich, weil niemand 
weiß, was was ist.

Ist insgesamt ein etwas spezieller Fall diese offenen Schiessanlagen.
Bei einigen (Kurzdistanz) sieht man wirklich eine Seilbahn (sogar 
mehrere nebeneinander): da werden die Schiesstafeln hin und her 
gefahren, damit der Schütze nach dem Schuss genau prüfen kann wie er 
getroffen hat.

Rückhol-Anlage, aber keine Seilbahn.
Weiteres Indiz: Google-Suche nach Schießen und Seilbahn findet etliche 
Ergebnisse, darunter hab ich aber kein einziges gesehen, das mit 
Seilbahn etwas anderes als den Lift (also nicht auf dem Schießstand) 
meint, bei Schießstand und Seilbahn sieht es nicht anders aus.

Die Ziellinie muss übrigens immer mindestens 1m über Boden sein.
Vielleicht ein layer=-1?
was willst du jetzt mit layer=-1 einzeichnen? das Datenkabel??? dann 
vielleicht, sonst nein.
Layer ist NUR für den Renderer da, und auch NUR, wenn der bei der 
Darstellung sonst Mist macht.

Werden befahrene Strassen überschossen, so sind diese ab Strassenniveau
um mindestens 4,5m durch Tiefblenden abzudecken.
Das wäre dann barrier=wall?

ja, könnte man machen.

Auch mit dem Scheibenstand bin ich noch nicht zufrieden:
Meist ist da ein aufgeschütteter Erdwall als Kugelfang (für alle die 
nicht so sicher treffen). Davor stehen die Scheissscheiben. Vor den 
Schiessscheiben ist ein Graben, in dem die Männer stehen/sitzen 
(amenity=bench?), meist überdacht (shelter=yes?), und einem 
(internen) Telefon zum Schützenhaus.

amenity=bench ist eine Bank, die sagt also nichts über den Graben.
Ist in dem Graben ein Weg? Dann vielleicht highway=footway mit 
cutting=yes (vgl. http://wiki.openstreetmap.org/wiki/Key:cutting)

Ich hätte mehr von dir erwartet ...

Man tut was man kann :-)
Vielleicht hast Du ja gute Ideen?

Gruss, Markus

PS: gibt es eigentlich im Wiki oder so eine 
Neuer-tag-Vorschlagsliste-für-Renderer? Also sowas wie aminity 
(oder man_made?) = Schusslinie und der Renderer zeichnet dann 
einen rötlichen Pfeil?

Erstmal kannst Du ein Proposal erstellen, da kannst Du das vorschlagen.
Wenn das angenommen ist (voting), kannst Du das natürlich den Admins der 
Renderer vorschlagen, du kannst aber auch deinen eigenen Renderer 
schreiben und das da übernehmen.

Eine Alternative wäre, Zone 1 als temporäre Sperrfläche einzutragen.
Aber da habe ich auch nichts wirklich passendes gefunden.
(braucht man eigentlich noch das area=yes - oder kann man dem 
Renderer in der Regeln sagen, dass es eine Fläche ist?)
area=yes ist immer sicherer; aber ja, man kann das auch in den Regeln 
sagen, wenn es denn IMMER eine Fläche ist (und nicht in ausnahmefällen 
auch mal ein geschlossener Linienzug sein kann)


Gruß
Peter

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

[Talk-de] Zeilenumbruch in name?

Hallo zusammen, 

gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B. Mapnick, 
Osmarender, ...) berücksichtigen. Wenn JA, welche?

Bespiel: 
http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M

Danke, mikeE63.

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

Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Matthias Versen


Hallo !


Das mit dem Punkt statt Flaeche auswerten finde ich eigentlich viel pfiffiger 
weil
eben es auch durchaus mal Straßen geben koennte die am Flughafen auf der 
falschen
Seite vorbeigehen. D.h. exakt die Position des Terminals mit einem Node zu 
markieren
ist sicherlich pfiffig (Ich meine mein Festeinbau kennt bei den großen 
Flughaefen sogar
die unterschiedlichen Terminals).


Der Flughafen ist zum Teil nach 
http://wiki.openstreetmap.org/wiki/Airports getaggt.


Warum findest Du den Punkt pfiffiger ?
Einfach in der Airport-Fläche nach Terminals suchen und den Namen 
anzeigen lassen sollte doch nicht schwer sein.


Dein Beispiel zeigt das Du nach dem Terminal des Flughafens suchen 
willst und nicht den Flughafen selber.


Matthias



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

Re: [Talk-de] Zeilenumbruch in name?

2010-10-06 Per discussione Sven Geggus

Elstermann, Mike mike.elsterm...@itc-halle.de wrote:

 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B.
 Mapnick, Osmarender, ...) berücksichtigen. Wenn JA, welche?
 
 Bespiel: 
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M

Die Editoren unterbinden das aber die API läßt das wohl zu. Jedenfalls gibt
es in der Datenbank solche Einträge.

Generell sollte man das aber definitiv dem renderer überlassen ob und wo er
Umbrüche einbaut.

Wir mappen nicht für den renderer

*SCNR*

Sven

P.S.: Warum schreibst Du das als Antwort auf ein ganz anderes Thema?

-- 
Das Einzige, wovor wir Angst haben sollten, ist die Angst selbst
(Franklin D. Roosevelt)

/me is gig...@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Carsten Schwede


Hallo,

Am 06.10.2010 10:34, schrieb Sven Geggus:

points:aeroway=airport [0x5900 resolution 23]
points:#sport=airport [0x2d0b resolution 14]
$ grep aerodrome *
points:aeroway=aerodrome [0x2f04 resolution 23]

Offensichtlich also nur die Punkte.



Wird eventuell beim mkgmap- Lauf dann die Option --add-pois-to-areas 
verwendet, dann erscheinen auch POIs auf den Flächen, auch wenn man es 
nicht expizit durch den Style festlegt.



--
Viele Gruesse
Computerteddy

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

Re: [Talk-de] Zeilenumbruch in name?

 Jedenfalls gibt es in der Datenbank solche Einträge.
Wie sehen die aus?

Generell sollte man das aber definitiv dem renderer überlassen ob und wo er 
Umbrüche einbaut.
Wir mappen nicht für den renderer
Na das ist schon klar - mir aber zu platt - Die Diskussion uralt. :-(

Trotzdem: Daten werden nicht um ihrer selbst Willen erfasst, sondern, um mit 
ihnen was zu machen und bei Geodaten ist das in den meisten Fällen die 
Präsentation - erst Recht bei OSM. Demzufolge wäre es schon gut zu wissen, wie 
ich als Mapper Präsentationen befruchten oder beeinflussen kann. Gerade der 
vernünftige Textsatz ist in der Kartographie schon immer ein RIESENTHEMA - 
erste Recht, wenn er automatisiert geschehen soll. Und da müssen sich 
Datenerzeuger - also Mapper - und Datenverarbeiter - also Renderer - treffen. 
Als Mitwirkender beim http://www.osmwms.de - hier schreiben wir ja den Renderer 
selbst - wäre es doch gut zu wissen, ob die Mapper da was berücksichtigen, dann 
könnten wir auch drauf reagieren.

Deswegen nochmal die Frage:

Gibt es Regeln, Vorschriften, ... wie ich schon beim Erfassen Zeilenumbrüche 
definieren kann oder gibt es einen Workaround für sowas? Welche Renderer 
unterstützen das wie?

Danke, mikeE63.


-Ursprüngliche Nachricht-
Von: talk-de-boun...@openstreetmap.org 
[mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Sven Geggus
Gesendet: Mittwoch, 6. Oktober 2010 11:38
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Zeilenumbruch in name?

Elstermann, Mike mike.elsterm...@itc-halle.de wrote:

 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B.
 Mapnick, Osmarender, ...) berücksichtigen. Wenn JA, welche?
 
 Bespiel: 
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M

Die Editoren unterbinden das aber die API läßt das wohl zu. Jedenfalls gibt
es in der Datenbank solche Einträge.

Generell sollte man das aber definitiv dem renderer überlassen ob und wo er
Umbrüche einbaut.

Wir mappen nicht für den renderer

*SCNR*

Sven

P.S.: Warum schreibst Du das als Antwort auf ein ganz anderes Thema?

-- 
Das Einzige, wovor wir Angst haben sollten, ist die Angst selbst
(Franklin D. Roosevelt)

/me is gig...@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Schiessstand Schweiz

2010-10-06 Per discussione Rolf Meyerhof

Hallo Markus

 

Dann ist das alles zusammen ein Schießanlage.

 

Gruß Rolf

 



From: talk-de-boun...@openstreetmap.org 
[mailto:talk-de-boun...@openstreetmap.org] On Behalf Of Markus
Sent: Wednesday, October 06, 2010 10:01 AM
To: Openstreetmap allgemeines in Deutsch
Subject: Re: [Talk-de] Schiessstand Schweiz

 

Hallo Rolf, 

 Schießbahn ist die Einrichtung auf der geschossen wird. 
 Schußbahn ist die Bahn auf der die Kugel oder das Geschoss fliegt. 

Ja, so kenne ich es auch. 

Bei einer Open-Air-Schiessbahn (wie in der Schweiz üblich) sieht man 
aber oft nur das Schützenhaus und den Scheibenstand. 
Das dazwischen ist unsichtbar - aber endgültig fühlbar (wenn man sich 
zur Unzeit dort hin verirrt). Eine Einrichtung ist da aber nicht. 
In der Kartografie wird das Dazwischen als Pfeil dargestellt. 

Schiessbahn ist also auch nicht so genau passend... 
Schussbahn meint genaugenommen: Hauptschussbahn (es gibt ja immer 
auch Fehlschüsse: siehe Sicherheitszone 2..5). 
Und genaugenommen müsste man je nach Anzahl der einzelnen Schiessstände 
mehrere Hauptschussbahnen einzeichnen (oder die eine mit lane=# ergänzen). 
Aber ich mag hier nicht auch noch die Diskussion Linienbündel vs. 
lanes führen - das erschine mir oversized... 

Gruss, Markus 

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

 

- 
eMail ist virenfrei. 
Von AVG Free SB überprüft - www.avg.de 
Version: 10.0.1120 / Virendatenbank: 422/3179 - Ausgabedatum: 05.10.2010 



eMail ist virenfrei.
Von AVG Free SB überprüft - www.avg.de
Version: 10.0.1120 / Virendatenbank: 422/3179 - Ausgabedatum: 05.10.2010 

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

Re: [Talk-de] Zeilenumbruch in name?


 On 06.10.2010 12:02, Elstermann, Mike wrote:

Jedenfalls gibt es in der Datenbank solche Einträge.

Wie sehen die aus?

Generell sollte man das aber definitiv dem renderer überlassen ob und wo er 
Umbrüche einbaut.
Wir mappen nicht für den renderer

Na das ist schon klar - mir aber zu platt - Die Diskussion uralt. :-(

Trotzdem: Daten werden nicht um ihrer selbst Willen erfasst, sondern, um mit 
ihnen was zu machen und bei Geodaten ist das in den meisten Fällen die 
Präsentation

in welcher Form?
Etliche nutzen OSM für Garmin-Navis - wenn ich das richtig im Kopf habe: 
keine Zeilenumbrüche,
Akustische Navigationssysteme (Kapten entwickelt für Autofahrer, 
loadstone und lorodux für Blinde) nutzen keine Zeilenumbrüche und kämen 
damit vermutlich teilweise nichtmal gut klar, ohne dass sie dafür 
angepasst würden), Auswertungen in Tabellen etc. werden von 
Zeilenumbrüchen auch keine Vorteile, sondern wenn überhaupt Nachteile 
haben, Listenfelder für die Suche sind problematisch, wenn sie 
Zeilenumbrüche beinhalten.

- erst Recht bei OSM. Demzufolge wäre es schon gut zu wissen, wie ich als 
Mapper Präsentationen befruchten oder beeinflussen kann. Gerade der vernünftige 
Textsatz ist in der Kartographie schon immer ein RIESENTHEMA - erste Recht, 
wenn er automatisiert geschehen soll. Und da müssen sich Datenerzeuger - also 
Mapper - und Datenverarbeiter - also Renderer - treffen. Als Mitwirkender beim 
http://www.osmwms.de - hier schreiben wir ja den Renderer selbst - wäre es doch 
gut zu wissen, ob die Mapper da was berücksichtigen, dann könnten wir auch 
drauf reagieren.

Mapper können nicht alle Anwendungsfälle berücksichtigen.
Wie mappen nicht für den Renderer - und nicht für irgendeine besondere 
andere Anwendung, wir mappen.


Ein Zeilenumbruch, der auf deinem Renderer gut aussieht, kann auf dem 
nächsten schon wieder total bescheiden aussehen, und in 'ner anderen 
Anwendung zu Problemen führen, die die Daten unbrauchbar machen.


Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche 
genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein 
Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde 
Idee.

Deswegen nochmal die Frage:

Gibt es Regeln, Vorschriften, ... wie ich schon beim Erfassen Zeilenumbrüche 
definieren kann oder gibt es einen Workaround für sowas? Welche Renderer 
unterstützen das wie?
Ich weiß keinen Renderer, der das unterstützt oder wo dies zumindest 
bewusst geschieht.
Zeilenumbrüche definieren: Gibt es meines Wissens noch nicht, ist meiner 
Meinung nach nicht sinnvoll oder notwendig.


Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht, 
selbst Zeilenumbrüche zu finden, wo keine definiert sind.

Warum also überhaupt welche angeben?

Gruß
Peter

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

Re: [Talk-de] Zeilenumbruch in name?

Am Mittwoch 06 Oktober 2010, 12:44:08 schrieb Peter Wendorff:
   On 06.10.2010 12:02, Elstermann, Mike wrote:
 Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche
 genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein
 Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde
 Idee.

ein Renderer der sowas fordert, macht definitiv etwas falsch.


 Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht,
 selbst Zeilenumbrüche zu finden, wo keine definiert sind.
 Warum also überhaupt welche angeben?
 

ganz einfach: damit die Anwendung sich evtl daran orientieren kann.

Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann Falls 
du umbrechen musst, dann mach's bevorzugt an dieser Stelle!.

Im einfachsten Fall koennte man dafuer einen Zeilenumbruch verwenden.
Was die jeweilige Anwendung dann daraus macht (irgendwie muss z.B. ein 
Renderer diese sowieso behandeln), bleibt ihr ueberlassen.






signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Das neue Taginfo

2010-10-06 Per discussione Heiko Jacobs


Am 05.10.2010 17:31, schrieb Jörg Ehrichs:

Dein TagInfo sieht echt toll aus. ganz besonders die Verteilung auf der Karte
ist ein sehr schönes Hilfsmittel.


Ja, nett, die Karte ;-)
Leider nur für den key, nicht auch für key-value-Kombis

Apropos Karte:
Was ich bisher vermisse bei anderne Tools und auch hier, ist die
Möglichkeit, zu key-value-Kombis hinzuspringen.

Wenn ich mich zu
surface=Metallbau␣Leuprecht
durchgehangelt habe, kann ich das aus der API runterladen,
aber als erstes würde mich vielleicht eher das Umfeld interessieren,
wo das auftritt. Nun gut, vielleicht nicht so der Metallbau, das
dürfte ein Fehler sein, den man gleich in JOSM laden könnte
(so man JOSM-Fan ist und nicht potlatch-Fan wie ich ;-) )
aber bei surface=woodchip bspw. würde mich das Biotop interessieren,
in dem diese Spezies residiert. Dazu fehlt entweder eine passende
Karte wie oben oder, wahrscheinlich einfacher, eine Liste von Links
zu den (ersten x) der ways/nodes/... mit dieser Kombis
auf bspw. http://www.openstreetmap.org/browse/way/4711


Was mir gerade auffiel:
Wenn ich bei der Anzeige eines keys auf 40 EInträge umschalte,
mich durch paar Seiten hangel, dann auf eine key-value-Kombi
klicke und mit dem Browser-Zurück zurückgehe, bin ich wieder
bei 15 auf Seite 1 ... Bisschen lästig ...

Gruß Mueck


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

Re: [Talk-de] Zeilenumbruch in name?


 On 06.10.2010 13:04, Guenther Meyer wrote:

Am Mittwoch 06 Oktober 2010, 12:44:08 schrieb Peter Wendorff:

   On 06.10.2010 12:02, Elstermann, Mike wrote:
Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche
genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein
Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde
Idee.

ein Renderer der sowas fordert, macht definitiv etwas falsch.



Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht,
selbst Zeilenumbrüche zu finden, wo keine definiert sind.
Warum also überhaupt welche angeben?


ganz einfach: damit die Anwendung sich evtl daran orientieren kann.

Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann Falls
du umbrechen musst, dann mach's bevorzugt an dieser Stelle!.

Mit welchen Randbedingungen denn?
Warum bricht eine Anwendung um?
Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn 
verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler 
werden?


Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll 
ist - aber bitte schreibt doch einfach welche ;)


Gruß
Peter

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

Re: [Talk-de] Das neue Taginfo

2010-10-06 Per discussione Sebastian Klein


Jochen Topf wrote:

Das ist ein halb-breites Leerzeichen (thinsp;). Du bist jetzt schon der
zweite, der das mit Opera unter Windows nicht angezeigt bekommt. Unter IE,
FF, Chrome und Opera 9 unter Linux tut es. Also das würde ich mal als Bug
bei Opera einstufen. Kannst Du ggf. ja mal bei denen melden.


Bekomme die Box auch unter Ubuntu mit Opera 10.61. Da es aber offenbar 
ein Fehler bei Opera ist, kann ich damit leben.


Sebastian


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

Re: [Talk-de] Schiessstand Schweiz

2010-10-06 Per discussione Micha Ruh

Ich habe die Schiessstände nach folgendem Schema gemapped.

http://www.openstreetmap.org/?lat=47.652563lon=8.830605zoom=18

Süd-östlich davon steht noch ein Armbruststand.

Funktioniert gut für 300m und 30m.


Gruëss, Micha
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schiessstand Schweiz


Hallo Peter,


Osmarender ist Osmarender


Klar - aber witzig ist es schon, dass er Sesselbahnen so zeichnet, dass 
die Sessel in den Himmel zeigen und die Touristen kopfüber nach unten 
hängen ;-)


Eine Seilbahn ist eine Seilbahn.
Also eine Transporteinrichtung, die Objekte an einem Seil befestigt von 
A nach B transportiert.
Das Problem ist - wie so oft bei unseren Attributen - dass mehrere 
Klassen in einem Attribut vermengt werden. Hier: Die Transportart, die 
Art der Transportbehälter, und die transportierten Gegenstände.


Dass Sessellift hier nicht passt ist klar.


Seilbahn passt eben nicht.


Die Anlage sieht so aus: zwischen Schützenhaus und Scheibenstand sind je 
Schiessstand zwei Drahtseile gespannt, auf denen ein Wagen mit Rollen 
fährt. Dieser wird mit einem Seilzug hin- und hergezogen.

http://www.psbuechberg.ch/bilder/schiessstand.gross.jpg
http://www.ps-hoffeld.ch/images/Anlage/50Meter_2.jpg


Rückhol-Anlage, aber keine Seilbahn.


Transportmechanismus: Seilbahn
Transportrichtung: bidirektional
Transporteinrichtung: Wagen auf 2 Tragseilen
Transportgut: Schiessscheibe


Die Ziellinie muss übrigens immer mindestens 1m über Boden sein.
Vielleicht ein layer=-1?


Sorry, Tipfehler. Richtig wäre: layer=1 für die Schussbahn


Layer ist NUR für den Renderer da, und auch NUR, wenn der bei der
Darstellung sonst Mist macht.


Habe jetzt den Sicherheitsbereich 2 eingezeichnet.
Der überdeckt aber den Wald (zumindest wenn der Wald Mischwald ist).
Mit layer=-1 wird auch der Mischwald wieder angezeigt.
(aber das ist jetzt wirklich Tagging für den Renderer)
Ideal wäre, wenn der Renderer solche Flächen transparent anzeigt.

Der Scheibenstand ist je nach Bauart eher eine Art Schützengraben (im 
Gelände vertieft), oder ein Bunker oberirdisch oder hinter einem 
künstlichen Wall/Mauer.



area=yes ist immer sicherer


Hab's getestet: ist bei military=danger_area nicht erforderlich.


Fläche - geschlossener Linienzug


Mapik macht hier nur Fläche.

Gruss, Markus

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

Re: [Talk-de] Zeilenumbruch in name?

 Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll ist 
 - aber bitte schreibt doch einfach welche ;)
Hab ich schon in der ersten Anfrage:
Siehe hier Bsp. 1:
Beispiel: 
http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M 
SO ist wohl nicht glücklich.

Bsp. 2: Und SO auch nicht: 
http://www.openstreetmap.org/?lat=51.47707lon=11.97303zoom=17layers=O

Übrigens:
Akustische Navigationssysteme, Garmins, ... sind auch nur Renderer.
Wenn es hinterfragte Regeln sinnvollerweise gäbe und diese bekannt wären oder 
eingeführt würden, könnten die verschiedenen Renderer auch drauf reagieren.
Das Leerzeichen als Kennzeichen eines möglichen Umbruchs ist definitiv zu wenig!
Z.B. Hausumbruch33: Spielehaus - besser wäre Haus 33:umbruchSpielehaus

Im Übrigen war meine Frage die nach einem Tipp, nicht die nach einer schon 
uralten Grundsatzdiskussion (Wir mappen nicht für den renderer). Das es das 
Angefragte nicht gibt und nach Meinung einiger auch nicht geben soll (was ich 
nicht nachvollziehen kann), werde ich mir weiterhin die Daten vom Planeten 
holen und gezwungener Weise speziell händisch behandeln und weiter damit leben, 
daß genau diese Daten in den gängigen Renderern der OSM-Welt bzgl. der Texte 
kartografisch katastrophal(! Siehe oben Beispiel 1...2) aussehen und die 
OSM-Gegner mit ihren platten Kommentaren zu den kartografischen Anfängerfehlern 
im OSM-Bereich auch noch Recht haben. SCHADE!

mikeE63.

-Ursprüngliche Nachricht-
Von: talk-de-boun...@openstreetmap.org 
[mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Peter Wendorff
Gesendet: Mittwoch, 6. Oktober 2010 13:13
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Zeilenumbruch in name?

  On 06.10.2010 13:04, Guenther Meyer wrote:
 Am Mittwoch 06 Oktober 2010, 12:44:08 schrieb Peter Wendorff:
On 06.10.2010 12:02, Elstermann, Mike wrote:
 Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche
 genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein
 Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde
 Idee.
 ein Renderer der sowas fordert, macht definitiv etwas falsch.


 Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht,
 selbst Zeilenumbrüche zu finden, wo keine definiert sind.
 Warum also überhaupt welche angeben?

 ganz einfach: damit die Anwendung sich evtl daran orientieren kann.

 Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann Falls
 du umbrechen musst, dann mach's bevorzugt an dieser Stelle!.
Mit welchen Randbedingungen denn?
Warum bricht eine Anwendung um?
Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn 
verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler 
werden?

Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll 
ist - aber bitte schreibt doch einfach welche ;)

Gruß
Peter

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

Re: [Talk-de] Zeilenumbruch in name?

Am Mittwoch 06 Oktober 2010, 13:13:28 schrieb Peter Wendorff:
  Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann
  Falls du umbrechen musst, dann mach's bevorzugt an dieser Stelle!.
 
 Mit welchen Randbedingungen denn?
 Warum bricht eine Anwendung um?
 Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn
 verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler
 werden?

das weiss nur der Renderer.
Aber wenn er umbrechen muss, dann kann er es erstmal an der gewuenschten 
Stelle versuchen, bevor er sich selber irgendeine brauchbare Stelle sucht.


 Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll
 ist - aber bitte schreibt doch einfach welche ;)

hier ein fiktives Beispiel:
name = Kartographie- und Datenamt Musterstadt Aussenstelle Nord-West II

Hier bricht man sinnvollerweise nach dem Ort um, falls noetig. Nur wie soll 
ohne Hinweis ein Renderer das wissen? Den Kontext versteht er nicht...




signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Florian Lohoff

On Wed, Oct 06, 2010 at 11:28:11AM +0200, Matthias Versen wrote:
 Warum findest Du den Punkt pfiffiger ?
 Einfach in der Airport-Fläche nach Terminals suchen und den Namen  
 anzeigen lassen sollte doch nicht schwer sein.

Das das Mathematisch nicht schwer ist mag ja sein - Welches Navi oder Konverter
macht das und wo kann ich mir das ansehen?

 Dein Beispiel zeigt das Du nach dem Terminal des Flughafens suchen  
 willst und nicht den Flughafen selber.

Das Terminal ist auch nur ein POI.

Flo
-- 
Florian Lohoff f...@zz.de
 Professionell gesehen bin ich zu haben 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zeilenumbruch in name?

2010-10-06 Per discussione Fabian Schmidt



Am 06.10.10 schrieb Elstermann, Mike:

gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
Zeilenumbrüche zu definieren,



Bespiel: 
http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M


wenn Du die Bibliotheksnamen meinst: da sollte es schon helfen, wenn der 
Stilpfleger einen Umbruch erlauben würde (wie weiter nördlich bei der 
Kafferösterei). Falls Du Dich an den schlecht umgebrochenen Häusernamen 
störst, dann bastle einen Renderer, der zusätzliche Attribute mit 
Rendererhinweisen auswertet, aber lasse bitte den Namen unangetastet:


name:renderhint = umbr...@12,50;n...@27;achtelgevi...@27


Gruß, Fabian.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zeilenumbruch in name?

Am Mittwoch 06 Oktober 2010, 13:49:29 schrieb Elstermann, Mike:
  Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll
  ist - aber bitte schreibt doch einfach welche ;)
 
 Hab ich schon in der ersten Anfrage:
 Siehe hier Bsp. 1:
 Beispiel:
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M
  SO ist wohl nicht glücklich.
 
 Bsp. 2: Und SO auch nicht:
 http://www.openstreetmap.org/?lat=51.47707lon=11.97303zoom=17layers=O

ich wusste, dass es reale Bespiele gibt ;-)


 Das Leerzeichen als Kennzeichen eines möglichen Umbruchs ist
 definitiv zu wenig! Z.B. Hausumbruch33: Spielehaus - besser wäre Haus
 33:umbruchSpielehaus

Ein Leerzeichen, bei dem nicht umgebrochen werden darf, gibt's in Unicode 
unter U+00A0 (in HTML bekannt als nbsp;).
Dann muesste man hierfuer zumindest nicht das Rad neu erfinden; stellt sich 
nur noch die Frage, wie man das im Editor eingibt...





signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?

2010-10-06 Per discussione Matthias Versen


Florian Lohoff wrote:


Das das Mathematisch nicht schwer ist mag ja sein - Welches Navi oder Konverter
macht das und wo kann ich mir das ansehen?


Keine Ahnung welches Navi das unterstützt aber das würde für mich zum 
normalen preprocessing der Daten gehören.
Allerdings frage ich mich was für eine Rolle es spielt ob ein Navi das 
derzeitig unterstützt oder nicht.




Dein Beispiel zeigt das Du nach dem Terminal des Flughafens suchen
willst und nicht den Flughafen selber.


Das Terminal ist auch nur ein POI.


Sicher aber was sagt mir das jetzt ?

Matthias



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

Re: [Talk-de] Zeilenumbruch in name?

2010-10-06 Per discussione Gary68

hi,

so sehr ich das auch verstehe. es gibt viele argumente dagegen. viele
schon beschrieben. ein renderer ist übrigens auch kein textprogramm, das
einen text schreibt. es wird den vorhandenen text zerlegen und so
viele zeilen anlegen, wie es braucht. der text wird dann in teilen dort
hineingeschrieben/-gemalt. ein return oder LF wird da nicht fruchten!
die höherwertigen renderer werden sogar jedes zeichen einzeln setzen!
CR/LF = unsichtbar.

es ist bei deinen beispielen stets der renderer zu verbessern! oder
manuelle nacharbeit notwendig. perfekt werden sie aber wohl erst später.
einfach mal ein wenig literatur zum thema lesen, da kann einem schon
schlecht werden, wenn man sowas einigermaßen vernünftig machen möchte...

und nochmal: die trennstelle ergibt sich NACH platz, textlänge, font,
fontgröße etc.

viele grüße

gerhard


On Wed, 2010-10-06 at 11:27 +0200, Elstermann, Mike wrote:
 Hallo zusammen, 
 
 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B. Mapnick, 
 Osmarender, ...) berücksichtigen. Wenn JA, welche?
 
 Bespiel: 
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M
 
 Danke, mikeE63.
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de



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

Re: [Talk-de] Zeilenumbruch in name?

2010-10-06 Per discussione Tobias Knerr

Am 06.10.2010 11:27, schrieb Elstermann, Mike:
 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B. Mapnick, 
 Osmarender, ...) berücksichtigen.

Meines Wissens ist kein solches Tagging vorgesehen.

Render-Hints (oder Hilfestellungen für andere Arten von Anwendungen)
sind an sich ein kontroverses Thema. Mindestanforderung an so etwas ist
aber in meinen Augen:

1. Es darf keine Konflikte mit etablierten Tags und anderen
Anwendungsmöglichkeiten der Daten erzeugen.
2. Wenn eine bessere Anwendung auch mit den existierenden Daten auskäme,
hat es in der Datenbank nichts zu suchen, sondern es müssen die
Anwendungen verbessert werden.
3. Es muss von allgemeinem Nutzen sein, also nicht nur für eine einzige
Anwendung/Schriftgröße/Auflösung/... gelten.

Für den vorliegenden Fall heißt das unter anderem, dass auf keinen Fall
das name-Tag selbst mit solchen Hinweisen angereichert werden, sondern
ein neu zu erfindendes Tag verwendet werden sollte. Außerdem wäre zu
überlegen, ob eine Regel in der Art bevorzugt an Leerzeichen nach
Doppelpunkten umbrechen nicht schon das gewünschte Resultat bringen
würde, oder ob es da nachteilige Nebenwirkungen gäbe.

Tobias Knerr

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

Re: [Talk-de] Zeilenumbruch in name?

ein renderer ist übrigens auch kein textprogramm
Hm... war ja auch nicht zu erwarten - nicht mal ich hätte das vermutet ;-)
 
es ist bei deinen beispielen stets der renderer zu verbessern!
Woher soll der Renderer das wissen?

und nochmal: die trennstelle ergibt sich NACH platz, textlänge, font, 
fontgröße etc.
Und nochmal: genau diese Automatismen arbeiten fast immer NICHT 
zufriedenstellend, deshalb sollte man das Ganze eben erweitern.

und nochmal: die trennstelle ergibt sich NACH platz, textlänge, font, 
fontgröße etc.
Mit Verlaub: Genau das ist für gute Kartografie/Textsatz viel zu wenig - reicht 
einfach nicht, ist viel zu oberflächlich...

Und nochmal 2:
Am Ende geht es doch den meisten bei der Beschäftigung mit Geodaten um deren 
Präsentation. Diese sollte optimal...perfekt sein (Endziel). Und wenn die 
Algorithmen das von allein nicht können, weil sie nicht alle Informationen 
haben, dann muss man ihnen die Informationen geben, z. B. in den Daten.

mikeE63.

-Ursprüngliche Nachricht-
Von: talk-de-boun...@openstreetmap.org 
[mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Gary68
Gesendet: Mittwoch, 6. Oktober 2010 14:14
An: Openstreetmap allgemeines in Deutsch
Betreff: Re: [Talk-de] Zeilenumbruch in name?

hi,

so sehr ich das auch verstehe. es gibt viele argumente dagegen. viele
schon beschrieben. ein renderer ist übrigens auch kein textprogramm, das
einen text schreibt. es wird den vorhandenen text zerlegen und so
viele zeilen anlegen, wie es braucht. der text wird dann in teilen dort
hineingeschrieben/-gemalt. ein return oder LF wird da nicht fruchten!
die höherwertigen renderer werden sogar jedes zeichen einzeln setzen!
CR/LF = unsichtbar.

es ist bei deinen beispielen stets der renderer zu verbessern! oder
manuelle nacharbeit notwendig. perfekt werden sie aber wohl erst später.
einfach mal ein wenig literatur zum thema lesen, da kann einem schon
schlecht werden, wenn man sowas einigermaßen vernünftig machen möchte...

und nochmal: die trennstelle ergibt sich NACH platz, textlänge, font,
fontgröße etc.

viele grüße

gerhard


On Wed, 2010-10-06 at 11:27 +0200, Elstermann, Mike wrote:
 Hallo zusammen, 
 
 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B. Mapnick, 
 Osmarender, ...) berücksichtigen. Wenn JA, welche?
 
 Bespiel: 
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M
 
 Danke, mikeE63.
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de



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

Re: [Talk-de] Zeilenumbruch in name?


Hallo Mike,


gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name 
Zeilenumbrüche zu definieren


Man könnte das Äquivalent für br in UTF-8 nehmen.

Der Renderer teilt lange Namen meist sequentiell in mehrere gleichlange 
Teile, beispielsweise in der Hälfte, beim nächsten Leerzeichen, oder 
er wählt eine maximale Zeilenlänge und schiebt den Rest in die nächste 
Zeile.


Eine semantische Analyse der Strings kann er nicht leisten, da er die 
vom Datensammler gemeinte Semantik nicht ahnen kann. Entsprechend 
erzeugt er dann oft unpassende Ergebnisse.


Es wäre sicher hilfreich, wenn Leerzeichen als Hinweis auf 
Soll/kann-Umbruchstellen durch br fallweise ersetzt werden könnten.


Gruss, Markus

PS: Satzzeichen, die als semantische Trenner bewertet werden könnten, 
sind in Namen eher selten. Wenn es solche aber gibt kann der Renderer 
damit durchaus ebenfalls einiges anfangen.


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

Re: [Talk-de] Zeilenumbruch in name?

Am Mittwoch 06 Oktober 2010, 14:46:14 schrieb Tobias Knerr:
 Render-Hints (oder Hilfestellungen für andere Arten von Anwendungen)
 sind an sich ein kontroverses Thema. Mindestanforderung an so etwas ist
 aber in meinen Augen:
 
 1. Es darf keine Konflikte mit etablierten Tags und anderen
 Anwendungsmöglichkeiten der Daten erzeugen.

das haengt davon ab, wie man es loest. Zumindest mit Unicode-Zeichen sollten 
alla Anwendungen umgehen koennen.

 2. Wenn eine bessere Anwendung auch mit den existierenden Daten auskäme,
 hat es in der Datenbank nichts zu suchen, sondern es müssen die
 Anwendungen verbessert werden.

Eine Anwendung kann nicht alles wissen, warum soll man ihr bekannte und 
hilfreiche Informationen nicht zur Verfuegung stellen?


 3. Es muss von allgemeinem Nutzen sein, also nicht nur für eine einzige
 Anwendung/Schriftgröße/Auflösung/... gelten.

Ein Hinweis hier sollst du bevorzugt umbrechen, falls noetig oder hier nach 
Moeglichkeit nicht umbrechen oder sematisch ausgedrueckt dieser Bereich 
gehoert zusammen *ist* allgemein sinnvoll...

 Für den vorliegenden Fall heißt das unter anderem, dass auf keinen Fall
 das name-Tag selbst mit solchen Hinweisen angereichert werden, sondern
 ein neu zu erfindendes Tag verwendet werden sollte. 

... und ist Teil der Textinformation selbst; in einem zweiten Tag also nicht 
wirklich sinnvoll.

 Außerdem wäre zu
 überlegen, ob eine Regel in der Art bevorzugt an Leerzeichen nach
 Doppelpunkten umbrechen nicht schon das gewünschte Resultat bringen
 würde, oder ob es da nachteilige Nebenwirkungen gäbe.

Das ist ein guter Ansatz, der aber nicht immer nutzbar ist.



signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] OSM Statistik gesucht - Editierfrequenz von Tags

2010-10-06 Per discussione Christoph Wagner

Hallo Liste,

ich weiß es gibt da draußen ein Haufen Statistiken über OSM, aber zu
folgender Problematik hab ich keine Informationen gefunden:

Wie häufig werden bereits existierende Informationen wieder verändert?
Gibt es Unterschiede zwischen den Tags?


Es gibt bisher immer nur Informationen über die Nutzer und wieviel die
so ändern und beitragen, aber nicht aus Sicht der Daten.

Stelle mir da gerade eine Berechnung wie folgt vor:

Editierfrequenz = (Summe der Anzahl der Änderungen des Tags mit Key X)
/ ( (Summe der Lebensdauern von Key X an den jeweiligen Objekten)

Beispiel mit 3 Objekten. Es wird nur das highway-tag betrachtet und
die Zeit wird zur Vereinfachung in ticks angegeben.

Objekt 1:
nach 3 ticks hinzufügen von:
highway=residential
nach weiteren 4 ticks:
1. Änderung:
highway=service
nach 1 tick:
2. Änderung:
highway=living_street
10 ticks bis heute

Objekt 2:
nach 0 ticks:
highway=motorway
17 ticks bis heute

Objekt 3:
nach 0 ticks:
highway=unclassified
nach 7 ticks:
1. Änderung:
highway=road
nach 2 ticks:
2. Änderung:
highway=tertiary
nach 5 ticks:
3. Änderung:
löschung


Also:
3 Objekte, Insgesamt 5 Änderungen des highway-tags
Lebensdauer des highway-tags bei:
Objekt 1: 4+1+10=15 ticks
Objekt 2: 17 ticks
Objekt 3: 7+2+5=14 ticks

Editierfrequenz des highway-tags am Einzelobjekt:
Objekt 1: 2/15 Änderungen/tick
Objekt 2: 0/17 Änderungen/tick
Objekt 3: 2/14 Änderungen/tick

Mittelwert aller Änderungen pro Gesamtlebensdauer des Tags
(Editierfrequenz des Tags):
(2+0+2)/(15+17+14) = 4/49 Änderungen/tick

Und diese mittlere Editierfrequenz würde mich jetzt für die häufigsten
tagkeys der OSM-Datenbank interessieren.
Da würde dann so ne Statistik rauskommen:

highway: X Änderungen/Zeit
amenity: Y Änderungen/Zeit
...


Dafür müsste man allerdings erstmal die komplette OSM-historie in der
Datenbank haben und nen fetten Rechner der dann die Statistiken
rumrödelt.
Hab ich leider gerade nicht zur Hand.

Fragen an die Liste:
Hat jemand schonmal sowas in der Art gemacht? Gibt es vielleicht schon
fertiges Stats in der Richtung und ich habs nur nicht gefunden?
Findet ihr die Methode sinnvoll?
Kann mir jemand helfen sowas zu erstellen oder ist das eh
aussichtslos, weil die historie eh nicht so klar ist, bei den ganzen
API-Umstellungen?

Ich hätte sowas gerne für meine Diplomarbeit.
Ich arbeite an einem System, um OSM-Daten mit GPG zu signieren. Dabei
wäre es sehr hilfreich zu wissen, wie oft sich die Daten eigentlich
ändern.

Vielen Dank und Grüße aus Dresden
Christoph

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

Re: [Talk-de] Zeilenumbruch in name?

2010-10-06 Per discussione Christian H. Bruhn

am Mittwoch, 6. Oktober 2010 um 11:27 schrieb Mike Elstermann:

 gibt es eine Möglichkeit, in den Attribut-Einträgen, z. B. name
 Zeilenumbrüche zu definieren, welche die aktuellen Renderer (z. B.
 Mapnick, Osmarender, ...) berücksichtigen. Wenn JA, welche?

 Bespiel:
 http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M

Mach doch ein Mapnik-Ticket unter [1] auf, daß der Text umgebrochen
werden soll.

Es gibt einige Tags [2] speziell für Osmarender, die direkt das
Renderergebnis beeinflussen. Wenn überhaupt sollte man höchstens an so
etwas denken.

'name' sollte dafür nicht mißbrauchen. Es würden wohl auch nur wenige
Mapper einen Zeilenumbruch im Namen einfügen.

Wenn Du dann eine Karte hast, in der die Zeilenumbrüche dort sind, wo
Du sie für richtig hältst, kann es natürlich sein, daß ein zweiter
anderer Meinung ist und die Darstellung anders haben möchte.

Christian

P.S. Ich finde es mehr als merkwürdig, einerseits sehr viel Wert auf
eine schöne Kartendarstellung zu legen, aber selbst den Namen eines
Renderes falsch zu schreiben und hier in der Liste auf eine vorhandene
Mail zu antworten, anstatt einen neuen Thread zu erstellen.

[1] http://trac.openstreetmap.org/
[2] http://wiki.openstreetmap.org/wiki/Osmarender/Tags


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

[Talk-de] Aerowest: Bildflugwünsche und -tarife 2010

2010-10-06 Per discussione TobWen


Hallo,

Aerowest hat kürzlich die aktuellen Bildflugtarife veröffentlicht:
http://www.aerowest.de/tarif/

Auf der Seite kann man einen Ort angeben, der beflogen
werden soll. Man erhält dann automatische Auskunft über
die Kosten für verschiedene Auflösung und Luftbildarten.

Die Preise beziehen sich auf eine Vertriebslizenz, man
darf die Bilder also unbegrenzt weiterverkaufen!

Vielleicht ist es ja möglich, einen Partner zu finden,
der die Bilder sowieso kaufen möchte. Wenn die Befliegung
z.B. 9.000 EUR kostet, könnte OSM mit 1.000 EUR dabei
sein und die Stadtwerke oder die Kommune mit 8.000 EUR.

Über einen Nutzungsvertrag könnte OSM dann z.B. auf den
Weiterverkauf der Bilder verzichten, damit der Kommune
keine Einnahmen durch Drittverwertung verloren gehen.

Viele Grüße
Tobias

ps: Bei mir möchte das im Firefox 3.6.10 nicht richtig ;-(
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Aerowest-Bildflugwunsche-und-tarife-2010-tp5607208p5607208.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Relation runterladen?

2010-10-06 Per discussione Rainer Kluge

Hallo,

Am 05.10.2010 19:16, schrieb Carsten Gerlach:
 Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei (z.B. 
 germany.osm) verwenden kann, aus der die Relation extrahiert wird?

Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer Relation aus einer
solchen Datei auslesen, dann muss man die komplette Datei lesen.

Ein XML-Parser, den ich für die sauberste Lösung halte, stößt da schon bei
Bundesland-Dateien an Speichergrenzen, von der Rechenzeit ganz zu schweigen.
Dieses Verfahren habe ich probeweise implementiert, und es funktioniert bei
kleinen osm-Dateien für ein Gebiet mit etwa 20x20 km Seitenlänge gut. Aber schon
bei der baden-wuerttemberg.osm.bz2 bekomme ich einen out-of-memory-Fehler.

Als Alternative könnten die Daten mit dem Perl-Modul OSM::osm ausgelesen werden.
Da die Knoten, Wege und Relationen in dieser Reihenfolge in der osm-Datei
liegen, müsste die Datei dreimal durgegangen werden, einmal, um die Relation(en)
zu finden, dann die zugehörigen Wege und zuletzt die zugehörigen Knoten. Das
wäre wohl speichermäßig unproblematisch aber ebenfalls sehr zeitaufwendig.
Ausserdem müsste ich die gesamte Programmlogik ändern.

Beim Online-Zugriff über das API werden immer nur genau die Daten abgerufen, die
benötigt werden. Die übertragenen Datenmengen sind daher sehr gering. Außerdem
garantiert diese Methode die höchstmögliche Aktualität der Daten.

Aber wenn mir jemand ein überzeugendes Argument für das extrahieren einzelner
Relationen aus einer lokalen osm-Datei liefert, denke ich nochmals über eine
Implementierung mit OSM::osm nach.


 Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.

Da ich mich weder mit dem OSM-XML-Format noch mit der Erstellung von XML aus
Perl auskenne, sieht es da noch schlechter aus als beim ersten Wunsch. Aber auch
hier würde mich der Anwendungsfall interessieren.

Gruß
Rainer


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

Re: [Talk-de] Zeilenumbruch in name?

On 06.10.2010 13:49, Elstermann, Mike wrote:

Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll ist -
aber bitte schreibt doch einfach welche ;)

Hab ich schon in der ersten Anfrage:
Siehe hier Bsp. 1:
Beispiel: http://www.openstreetmap.org/?lat=51.477066lon=11.97303zoom=18layers=M

SO ist wohl nicht glücklich.

Bsp. 2: Und SO auch nicht:
http://www.openstreetmap.org/?lat=51.47707lon=11.97303zoom=17layers=O

Das Leerzeichen als Kennzeichen eines möglichen Umbruchs ist definitiv zu wenig!
Z.B. Hausumbruch33: Spielehaus - besser wäre Haus 33:umbruchSpielehaus
Ich gebe Dir recht, würde aber an diesem Punkt trotzdem den Renderer in
die Pflicht nehmen und Leerzeichen nach Interpunktionszeichen bevorzugt
als Umbruchstelle nutzen.
Das dürfte als Heuristik auch allgemeiner Gültigkeit haben, ohne
explizites Tagging zu erfordern.

Im Übrigen war meine Frage die nach einem Tipp, nicht die nach einer schon uralten
Grundsatzdiskussion (Wir mappen nicht für den renderer). Das es das
Angefragte nicht gibt und nach Meinung einiger auch nicht geben soll (was ich nicht
nachvollziehen kann), werde ich mir weiterhin die Daten vom Planeten holen und
gezwungener Weise speziell händisch behandeln und weiter damit leben, daß genau diese
Daten in den gängigen Renderern der OSM-Welt bzgl. der Texte kartografisch katastrophal(!
Siehe oben Beispiel 1...2) aussehen und die OSM-Gegner mit ihren platten Kommentaren zu
den kartografischen Anfängerfehlern im OSM-Bereich auch noch Recht haben. SCHADE!
Ein anderer Punkt ist das, was Du eigentlich willst: Du willst nicht
ZUSÄTZLICHE Umbrüche oder BEVORZUGTE Umbrüche, du willst Umbrüche an
bestimmten Stellen vermeiden.
DAS ist aber meiner Meinung nach ein anderes Thema, DAS ist auch
berechtigt (abgesehen davon, dass, wie oben erwähnt, einiges auch im
Renderer gemacht werden könnte).

sowas wie nbsp; in html könnte da helfen - wie genau, muss man dann gucken.

Gruß
Peter

mikeE63.

-Ursprüngliche Nachricht-
Von: talk-de-boun...@openstreetmap.org
[mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Peter Wendorff
Gesendet: Mittwoch, 6. Oktober 2010 13:13
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Zeilenumbruch in name?

On 06.10.2010 13:04, Guenther Meyer wrote:

Am Mittwoch 06 Oktober 2010, 12:44:08 schrieb Peter Wendorff:

On 06.10.2010 12:02, Elstermann, Mike wrote:
Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche
genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein
Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde
Idee.

ein Renderer der sowas fordert, macht definitiv etwas falsch.

Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht,
selbst Zeilenumbrüche zu finden, wo keine definiert sind.
Warum also überhaupt welche angeben?

ganz einfach: damit die Anwendung sich evtl daran orientieren kann.

Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann Falls
du umbrechen musst, dann mach's bevorzugt an dieser Stelle!.

Mit welchen Randbedingungen denn?
Warum bricht eine Anwendung um?
Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn
verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler
werden?

Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll
ist - aber bitte schreibt doch einfach welche ;)

Gruß
Peter

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

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

Re: [Talk-de] Zeilenumbruch in name?


 On 06.10.2010 13:51, Guenther Meyer wrote:

Am Mittwoch 06 Oktober 2010, 13:13:28 schrieb Peter Wendorff:

Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn
verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler
werden?

das weiss nur der Renderer.
Aber wenn er umbrechen muss, dann kann er es erstmal an der gewuenschten
Stelle versuchen, bevor er sich selber irgendeine brauchbare Stelle sucht.
Nein: Stellen, an denen NICHT umgebrochen werden soll, wenn es IRGENDWIE 
vermeidbar ist, sollten entsprechend markiert werden, nicht andersherum.


Eine Lösung dafür hast Du ja selbst schon geschrieben.

Gruß
Peter

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

Re: [Talk-de] Zeilenumbruch in name?


 On 06.10.2010 14:45, Elstermann, Mike wrote:
Und nochmal: genau diese Automatismen arbeiten fast immer NICHT 
zufriedenstellend, deshalb sollte man das Ganze eben erweitern.

Siehe Lösungsvorschlag (für Renderer in meiner anderen Mail).

und nochmal: die trennstelle ergibt sich NACH platz, textlänge, font, fontgröße 
etc.

Mit Verlaub: Genau das ist für gute Kartografie/Textsatz viel zu wenig - reicht 
einfach nicht, ist viel zu oberflächlich...

Automatisiert funktioniert GUTE Kartografie nicht,
zumindest nicht, wenn nicht die Karte die einzige Anwendung der 
Datenbank sein soll.

Und nochmal 2:
Am Ende geht es doch den meisten bei der Beschäftigung mit Geodaten um deren 
Präsentation. Diese sollte optimal...perfekt sein (Endziel). Und wenn die 
Algorithmen das von allein nicht können, weil sie nicht alle Informationen 
haben, dann muss man ihnen die Informationen geben, z. B. in den Daten.

Dass das nicht geht, davon bin ich, wie gesagt, noch nicht überzeugt.
Weitere Beispiele mit anderen Fehlern her ;)

Gruß
Peter

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

Re: [Talk-de] Zeilenumbruch in name?


 On 06.10.2010 15:09, Guenther Meyer wrote:

Außerdem wäre zu
überlegen, ob eine Regel in der Art bevorzugt an Leerzeichen nach
Doppelpunkten umbrechen nicht schon das gewünschte Resultat bringen
würde, oder ob es da nachteilige Nebenwirkungen gäbe.

Das ist ein guter Ansatz, der aber nicht immer nutzbar ist.

Gegenbeispiele bitte!

Gruß
Peter

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

Re: [Talk-de] Intergeo

2010-10-06 Per discussione TobWen


Verdammt, ich habe mein neues Semesterticket noch nicht :-(
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Intergeo-tp5605804p5607290.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Schiessstand Schweiz


 Hallo Markus.
Auf der einen Seite passt Du dein Tagging ganz bewusst für den Renderer 
an (layer=* etc.), auf der anderen Seite beschwerst Du dich über den 
Sessellift, weil das doch falsch wäre.
Die Seilbahn, die du getagged hast, IST eine Seilbahn, in der 
üblicherweise Menschen transportiert werden, also Skilifte, 
Bergseilbahnen etc.


Was also willst Du jetzt?
Taggen für den Renderer, oder den Renderer verbessern?
In letzterem Fall lass den Mist mit dem etablierten Seilbahn-Tag, such 
dir einen neuen, mach ein Proposal dazu und schlage den Rendering-Admins 
vor, das zu übernehmen.


Gruß
Peter

On 06.10.2010 13:41, Markus wrote:

Hallo Peter,


Osmarender ist Osmarender


Klar - aber witzig ist es schon, dass er Sesselbahnen so zeichnet, 
dass die Sessel in den Himmel zeigen und die Touristen kopfüber nach 
unten hängen ;-)


Eine Seilbahn ist eine Seilbahn.
Also eine Transporteinrichtung, die Objekte an einem Seil befestigt 
von A nach B transportiert.
Das Problem ist - wie so oft bei unseren Attributen - dass mehrere 
Klassen in einem Attribut vermengt werden. Hier: Die Transportart, die 
Art der Transportbehälter, und die transportierten Gegenstände.


Dass Sessellift hier nicht passt ist klar.


Seilbahn passt eben nicht.


Die Anlage sieht so aus: zwischen Schützenhaus und Scheibenstand sind 
je Schiessstand zwei Drahtseile gespannt, auf denen ein Wagen mit 
Rollen fährt. Dieser wird mit einem Seilzug hin- und hergezogen.

http://www.psbuechberg.ch/bilder/schiessstand.gross.jpg
http://www.ps-hoffeld.ch/images/Anlage/50Meter_2.jpg


Rückhol-Anlage, aber keine Seilbahn.


Transportmechanismus: Seilbahn
Transportrichtung: bidirektional
Transporteinrichtung: Wagen auf 2 Tragseilen
Transportgut: Schiessscheibe


Die Ziellinie muss übrigens immer mindestens 1m über Boden sein.
Vielleicht ein layer=-1?


Sorry, Tipfehler. Richtig wäre: layer=1 für die Schussbahn


Layer ist NUR für den Renderer da, und auch NUR, wenn der bei der
Darstellung sonst Mist macht.


Habe jetzt den Sicherheitsbereich 2 eingezeichnet.
Der überdeckt aber den Wald (zumindest wenn der Wald Mischwald ist).
Mit layer=-1 wird auch der Mischwald wieder angezeigt.
(aber das ist jetzt wirklich Tagging für den Renderer)
Ideal wäre, wenn der Renderer solche Flächen transparent anzeigt.

Der Scheibenstand ist je nach Bauart eher eine Art Schützengraben 
(im Gelände vertieft), oder ein Bunker oberirdisch oder hinter einem 
künstlichen Wall/Mauer.



area=yes ist immer sicherer


Hab's getestet: ist bei military=danger_area nicht erforderlich.


Fläche - geschlossener Linienzug


Mapik macht hier nur Fläche.

Gruss, Markus

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



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

Re: [Talk-de] Schiessstand Schweiz