Re: [Talk-de] TüV Reinland Breitbandatlas basiert a uf OSM-Daten

[Thomas Reincke]

Am 07.10.2010 06:22, schrieb Björn Sieper:

d>  Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;)
Ganz so merkwürdig find ich das garnicht. In Wirklichkeit macht die
Seite selber vermutlich irgendein Computerfreak und wenn der keine
konkrete Vorgabe kriegt welche Karte er verwenden soll dann ist der
Bezug zu "offen" bei diesem Klientel im Zweifel relativ hoch.


Meine Erfahrung mit Werbe-/Webagebturen ist ein "was der Bauer nicht 
kennt, daß frisst er nicht". Entsprechend wird dann versucht, Google 
Maps zu verwenden. "Die API kennen wir",


Den Unterschied zwischen Kartenclient und Kartenmaterial muß man auch 
immer wieder erklären. Erst wenn man die Google-Karte in 
Mapnik(map.sautter.com) oder die OSM-Karte in der Google-API 
(gpswandern.de) zeigt, wird das für viele klar.


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

Re: [Talk-de] TüV Reinland Breitbandatlas basiert a uf OSM-Daten

[Björn Sieper]

Hi,

d> Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;)
Ganz so merkwürdig find ich das garnicht. In Wirklichkeit macht die
Seite selber vermutlich irgendein Computerfreak und wenn der keine
konkrete Vorgabe kriegt welche Karte er verwenden soll dann ist der
Bezug zu "offen" bei diesem Klientel im Zweifel relativ hoch.


Gruß!!!


___
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?

[M∡rtin Koppenhoefer]

Am 7. Oktober 2010 00:35 schrieb Friedhelm Schmidt :
> Am 06.10.2010 22:14, schrieb Garry:
>>
>> für den Luftverkehr (Piloten,..) aeroway=...
>
> Mit Verlaub: Für den Luftverkehr ist OSM hierzulande momentan bedeutungslos.
> Da schreibt das Gesetz präzise vor, welche Karten zu verwenden sind - kein
> Spielraum.


Man kann das Wort "Pilot" ja etwas weiter auffassen und z.B. auf die
Piloten von Flugsimulatoren ausdehnen.

Gruß Martin

___
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?

[Friedhelm Schmidt]

Am 06.10.2010 22:14, schrieb Garry:

für den Luftverkehr (Piloten,..) aeroway=...


Mit Verlaub: Für den Luftverkehr ist OSM hierzulande momentan 
bedeutungslos. Da schreibt das Gesetz präzise vor, welche Karten zu 
verwenden sind - kein Spielraum.


Interessant könnte OSM aber für den Luftsport sein. Auch hier gilt zwar 
zunächst das oben gesagte.


Aber: Aus unseren Daten über Hochspannungstrassen etc. könnten man 
*zusätzliche* Karten oder Overlays mit Luftfahrthindernissen erstellen, 
die Ballonfahrern oder Segelfliegern bei der Vorbereitung von 
Aussenlandungen wertvolle Hinweise geben.


Mit Fliegergruß (Grmpfff :-) )

-fri-




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

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

[Walter Nordmann]

joo, da haste - leider - recht :( ich hatte nicht an die history gedacht, die
ist in der 'simple' ja 
nicht drin.

dann bleiben ja wohl nur noch deine hstore-scripts über oder man erweitert
die von brett.

also mir wäre der ganze aufwand für "eine einfache auswertung" doch echt zu
groß.

gruss
walter

-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/OSM-Statistik-gesucht-Editierfrequenz-von-Tags-tp5607138p5609209.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] Zeilenumbruch in "name"?

[Guenther Meyer]

Am Mittwoch 06 Oktober 2010, 23:54:35 schrieb Ulf Lamping:
> Am 06.10.2010 23:35, schrieb Guenther Meyer:
> > Am Mittwoch 06 Oktober 2010, 15:57:06 schrieb Christian H. Bruhn:
> >> Es gibt einige Tags [2] speziell für Osmarender, die direkt das
> >> Renderergebnis beeinflussen. Wenn überhaupt sollte man höchstens an so
> >> etwas denken.
> > 
> > -1
> > keine Spezialtags fuer irgendeine spezielle Software!
> 
> +1
> 
> Allerdings denke ich da eher an sowas wie name="plain text" (für die
> bisherige "raw" Form) und name:line_wrapped="plaintext" (oder wie
> auch immer) für spezielle Formatierungshinweise.

Wozu? Das macht doch alles nur unnoetig kompliziert.

Statt einem normalen Leerzeichen benutzt man an den entsprechenden Stellen 
einfach ein "geschuetztes Leerzeichen".


> >> 'name' sollte dafür nicht mißbrauchen. Es würden wohl auch nur wenige
> >> Mapper einen Zeilenumbruch im Namen einfügen.
> > 
> > das ist kein Missbrauch.
> 
> Jein. Führt aber aller Vorraussicht nach zu allen möglichen Problemen.

zum Beispiel?

 
> > Und wer's nicht eintragen will, traegt's halt nicht ein. Das soll aber
> > den anderen nicht die Moeglichkeit nehmen, sinnvolle Informationen
> > einzutragen...
> 
> Sehe ich ähnlich. Sollte aber *zusätzlich* zu den bisherig üblichen
> Infos eingetragen werden, nicht anstelle von.

s.o.

 
> >> 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.
> > 
> > Es ist ein Unterschied, ob man eine bestimmte Darstellung fuer ein
> > bestimmes Renderering in einer bestimmten Schriftart und -groesse zu
> > erzwingen versucht, oder ob man der Software einen Hinweis gibt, welche
> > Teile des Namens sinngemaess zusammengehoeren und auch besser
> > entprechend dargestellt werden sollten.
> 
> Klingt jetzt für mich so, das Mapper diese "nicht Trennzeichen" an einer
> bestimmten Stelle eintragen, weil es bei einem bestimmten Renderer dort
> so paßt, beim anderen Renderer aber leider dann wieder nicht.

Die Gefahr dieses Missbrauchs besteht immer, ist auch nix neues bei OSM.
Ich finde das aber weniger schlimm, als Schiessplatzbeestandteile als 
Sessellifte zu taggen ;-)

Abgesehen davon:
Ich gehe davon aus, dass *wenn* Renderer das auswerten, meist was 
vernuenftiges bei rauskommt, waehrend das bei einem Renderer,der sich nicht 
dafuer interessiert, sowieso keinen Unterschied macht.



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] Zeilenumbruch in "name"?

[Ulf Lamping]

Am 06.10.2010 23:35, schrieb Guenther Meyer:

Am Mittwoch 06 Oktober 2010, 15:57:06 schrieb Christian H. Bruhn:

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


-1
keine Spezialtags fuer irgendeine spezielle Software!

+1

Allerdings denke ich da eher an sowas wie name="plain text" (für die 
bisherige "raw" Form) und name:line_wrapped="plaintext" (oder wie 
auch immer) für spezielle Formatierungshinweise.



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


das ist kein Missbrauch.


Jein. Führt aber aller Vorraussicht nach zu allen möglichen Problemen.


Und wer's nicht eintragen will, traegt's halt nicht ein. Das soll aber den
anderen nicht die Moeglichkeit nehmen, sinnvolle Informationen einzutragen...


Sehe ich ähnlich. Sollte aber *zusätzlich* zu den bisherig üblichen 
Infos eingetragen werden, nicht anstelle von.



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.


Es ist ein Unterschied, ob man eine bestimmte Darstellung fuer ein bestimmes
Renderering in einer bestimmten Schriftart und -groesse zu erzwingen versucht,
oder ob man der Software einen Hinweis gibt, welche Teile des Namens
sinngemaess zusammengehoeren und auch besser entprechend dargestellt werden
sollten.


Klingt jetzt für mich so, das Mapper diese "nicht Trennzeichen" an einer 
bestimmten Stelle eintragen, weil es bei einem bestimmten Renderer dort 
so paßt, beim anderen Renderer aber leider dann wieder nicht.


Gruß, ULFL

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

Re: [Talk-de] Relation führt über area -> Lü cke

[Robert Heel]

Am 05.10.2010 10:30, schrieb Peter Wendorff:
> Geht damit nicht der eigentliche Vorteil von wegen gegenüber dem ganz frühen 
> Modell von Segmenten verloren?
> Wäre es nicht besser, eine Route "auf Weg A von Knoten B bis Knoten C" zu 
> führen?
+1

Das zerstückeln von Wegen finde ich auch nicht so schön. Eigentlich müsste man 
alle Wegschnipsel wieder in eine Relation
packen und dort erst die Tags setzen ...

Grüße,

Robert


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

Re: [Talk-de] TüV Reinland Breitbandatlas basiert au f OSM-Daten

[Martin Kaistra]

hm.. der Bodensee wurde nicht vollständig gerendert ;-)

Aber insgesamt ne coole Sache

Am Mittwoch, den 06.10.2010, 23:24 +0200 schrieb derandi: 
> Hi,
> 
> eben via golem.de gefunden.
> http://www.zukunft-breitband.de/BBA/Navigation/Breitbandatlas/breitbandsuche.html
> 
> Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;)
> 
> Schönen Abend.
> 
> ___
> 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"?

[Guenther Meyer]

Am Mittwoch 06 Oktober 2010, 15:57:06 schrieb Christian H. Bruhn:
> Es gibt einige Tags [2] speziell für Osmarender, die direkt das
> Renderergebnis beeinflussen. Wenn überhaupt sollte man höchstens an so
> etwas denken.

-1
keine Spezialtags fuer irgendeine spezielle Software!


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

das ist kein Missbrauch.
Und wer's nicht eintragen will, traegt's halt nicht ein. Das soll aber den 
anderen nicht die Moeglichkeit nehmen, sinnvolle Informationen einzutragen...

 
> 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.

Es ist ein Unterschied, ob man eine bestimmte Darstellung fuer ein bestimmes 
Renderering in einer bestimmten Schriftart und -groesse zu erzwingen versucht, 
oder ob man der Software einen Hinweis gibt, welche Teile des Namens 
sinngemaess zusammengehoeren und auch besser entprechend dargestellt werden 
sollten.


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] Zeilenumbruch in "name"?

[Guenther Meyer]

Am Mittwoch 06 Oktober 2010, 16:23:55 schrieb Peter Wendorff:
>   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!

Eine lange Bezeichnung in dem kein Doppelpunkt vorkommt!?
Beispiele wurden ja schon genannt.


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] Zeilenumbruch in "name"?

[Guenther Meyer]

Am Mittwoch 06 Oktober 2010, 16:17:58 schrieb Peter Wendorff:
>   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.

ob so oder so rum ist doch eigentlich egal, der Zweck bleibt derselbe; ...
 

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

 ...diese Methode hat sich halt schon woanders etabliert und als sinnvoll 
erwiesen.



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] TüV Reinland Breitbandatlas basiert a uf OSM-Daten

[derandi]

Hi,

eben via golem.de gefunden.
http://www.zukunft-breitband.de/BBA/Navigation/Breitbandatlas/breitbandsuche.html

Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;)

Schönen Abend.

___
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?

[Garry]

 Am 06.10.2010 09:55, schrieb Florian Lohoff:

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).

Für den Passagier sollte meiner Meinung nach amenity=airport relevant 
sein der als Poi auftauchen sollte, für den Luftverkehr (Piloten,..) 
aeroway=...
Eventuell sollte man sich aber auch noch Gedanken machen bzgl. 
Ankunft/Abflug/Parkmöglichkeiten für die Passagiere da die Wege sonst 
doch recht lange

werden können...

Garry

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

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

[M∡rtin Koppenhoefer]

Am 6. Oktober 2010 21:13 schrieb Johannes Huesing :
> M∡rtin Koppenhoefer  [Wed, Oct 06, 2010 at 08:16:55PM 
> CEST]:


>> man würde dann ja auch 0.2 schreiben und nicht 0.20. Das x finde ich
>> auch nicht gut. Wenn man 3 Werte hat, sollte man m.E. auch 3 keys
>> haben. Also
>>
>> locker:height:inner=0.5
>> locker:width:inner=0.2
>> locker:depth:inner=0.5
>>
>
> Und man muss Schließfächer einbeziehen können, deren Innenraum nicht
> quaderförmig ist.


man kann natürlich auch das "inner" weglassen, habe selbst etwas
gezögert, aber dann kommt halt der nächste, und mappt die Aussenmaße
der gesamten Schließfachanlage ebenfalls mit locker:height etc.

Gruß Martin

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

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

[Peter Körner]

Am 06.10.2010 21:39, schrieb Walter Nordmann:

schau dir mal osmosis 0.37 an (script-verzeichnis).
da ist hstore drin, und zwar direkt vom autor (brett)  :)
rennt bei mit seit 3 wochen. osm2psql ist - für mich - tot. und zwar
mausetot (drop database ...)


Die osmosis-Schemas können aber nicht mit mehreren Versionen für gleiche 
Objekte umgehen, dazu brauchst du ein anderes Schema und einen anderen 
Import-Prozess. Beides bietet das og. Plugin und dieser Teil sollte auch 
schon funktionieren.


Weitere Funktionen (minor-versions-builder, waynode-versions-builder, 
linestring-builder) funktionieren aber noch nicht.


Lg, Peter

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

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

[Johannes Huesing]

Peter Körner  [Wed, Oct 06, 2010 at 09:17:24PM CEST]:
> Am 06.10.2010 17:08, schrieb Christoph Wagner:
> >Hat jemand ne Ahnung wie groß das Ding in ner Datenbank ist?
> >Müsste ich mir bestimmt ne neue Festplatte holen...
> ich denke ne 1TB Platte wird's schon werden müssen (Schätzung!)

Aussagekräftiges bekommt man dann auch in einer Stichprobe mit etwa 1 Prozent 
der Daten, zumindest über die häufigeren Tags.


-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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

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

[Walter Nordmann]

schau dir mal osmosis 0.37 an (script-verzeichnis).
da ist hstore drin, und zwar direkt vom autor (brett)  :)
rennt bei mit seit 3 wochen. osm2psql ist - für mich - tot. und zwar
mausetot (drop database ...)

gruss
walter

-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/OSM-Statistik-gesucht-Editierfrequenz-von-Tags-tp5607138p5608639.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] Aerowest: Bildflugwünsche und -tarife 2010

[M∡rtin Koppenhoefer]

Am 6. Oktober 2010 16:05 schrieb TobWen :
> Aerowest hat kürzlich die aktuellen Bildflugtarife veröffentlicht:
> http://www.aerowest.de/tarif/


relativ billig wie ich finde.


> 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.


oder OSM bietet an, die Bilder im Rahmen von OSM zu vektorisieren und
Daten daraus abzuleiten, die dann in OSM zur Verfügung gestellt
werden, und dafür stellt der Luftbildvertriebslizenzbesitzer sie
kostenlos zur Verfügung? Oder wie sammeln Geld von Sponsoren, die
sowas finanzieren? Selbst Geld dafür zu bezahlen finde ich ein
bisschen absurd.

Man könnte auch durchaus nochmal versuchen, an die Vermessungsämter
heranzutreten, von oben, also über den Minister oder so, ggf. auch auf
Ländereben. Es gibt ja mittlerweile doch einige Länder in der EU, die
sich deutlich offener zeigen als Deutschland (UK, Frankreich,
Italien), vielleicht wirkt ja ein entsprechender Hinweis?

Gruß Martin

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

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

[Peter Körner]

Am 06.10.2010 17:08, schrieb Christoph Wagner:

Hat jemand ne Ahnung wie groß das Ding in ner Datenbank ist?
Müsste ich mir bestimmt ne neue Festplatte holen...

ich denke ne 1TB Platte wird's schon werden müssen (Schätzung!)


Was gibts so für Möglichkeiten/Tools, um das überhaupt in ne DB zu
bekommen? Geht da was mit osmosis?


Ich habe ein nicht-mal-halb-fertiges Plugin für Osmosis, das es dir 
erlauben sollte, ein simple-schema mit History-Informationen zu füllen:




Lg, Peter

___
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?

[M∡rtin Koppenhoefer]

Am 6. Oktober 2010 14:00 schrieb 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.


Wenn man von einer konkreten Karte (AIO) fürs Garmin spricht, dann
interessiert das natürlich schon. Schließlich will man die ja nutzen.
Wenn das irgendein Navi in einem Jahr unterstützen wird, dann
interessiert das hingegen überhaupt nicht, weil man dann sicher schon
eine andere Karte drauf haben wird, wenn man im OSM Umfeld aktiv ist.

Gruß Martin

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

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

[Johannes Huesing]

M∡rtin Koppenhoefer  [Wed, Oct 06, 2010 at 08:16:55PM 
CEST]:
> Am 6. Oktober 2010 09:16 schrieb Guenther Meyer :
> > Am Dienstag 05 Oktober 2010, 22:29:30 schrieb Johannes Huesing:
> >> olvagor  [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.
> 
> 
> man würde dann ja auch 0.2 schreiben und nicht 0.20. Das x finde ich
> auch nicht gut. Wenn man 3 Werte hat, sollte man m.E. auch 3 keys
> haben. Also
> 
> locker:height:inner=0.5
> locker:width:inner=0.2
> locker:depth:inner=0.5
> 

Und man muss Schließfächer einbeziehen können, deren Innenraum nicht
quaderförmig ist. 

Spätestens jetzt beginnt die Diskussion zu entgleiten.


-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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

Re: [Talk-de] Zeilenumbruch in "name"?

[Ulf Lamping]

Am 06.10.2010 13:49, 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.477066&lon=11.97303&zoom=18&layers=M 
"
SO ist wohl nicht glücklich.

Bsp. 2: Und SO auch nicht: 
http://www.openstreetmap.org/?lat=51.47707&lon=11.97303&zoom=17&layers=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. "Haus33: Spielehaus" - besser wäre "Haus 33:Spielehaus"

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!


Ich finde du setzt da (aktuell zumindest) an der falschen Stelle an.

Solche ewig langen Namen möchte ich eigentlich auf einer Karte wie bei 
OSM.org überhaupt nicht sehen (zumindest nicht in dieser Zoomstufe), 
egal mit welchem Umbruch. Ich rede jetzt nicht von einer "offiziellen 
Campuskarte", die laut Willen der Auftraggeber die offiziellen Namen 
beinhalten muß.



a) Also Tagging anstelle von:

name=Bibliothek des Studienzentrums August-Herman-Francke

eher sowas wie:

name=Bibliothek des Studienzentrums
official_name=Bibliothek des Studienzentrums August-Herman-Francke

damit hat man schonmal einen größeren Teil der "Umbruchs-Probleme" 
deutlich entschärft.



b) Das die Renderer hier allgemein noch Potenzial haben, ist wohl klar. 
Gibt es für mapnik schon einen Bugreport hierzu? Es macht wenig Sinn 
sich über Tag-Hinweise für den Renderer-Umbruch zu unterhalten, wenn die 
Renderer nicht mal "einfachen" Umbruch "sauber" beherrschen.



Wenn die Renderer hier besser geworden sind, kann man sich Gedanken 
machen, wie man den Renderern bei "den übriggebliebenen Sonderfällen" 
mit Hilfe von Spezialtags unter die Arme greifen kann. Erst dann weiß 
man aber auch, welche Sonderfälle man wirklich behandeln sollte - viele 
Probleme dürften sich dann nämlich schon von alleine gelöst haben.


Gruß, ULFL

P.S: Spricht jetzt nichts gegen das experimentieren mit Sondertags für 
solche Zwecke, aber bitte nicht direkt im name Tag ;-)


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

Re: [Talk-de] Schiessstand Schweiz

[M∡rtin Koppenhoefer]

Am 6. Oktober 2010 13:41 schrieb Markus :
> Eine Seilbahn ist eine Seilbahn.
> Also eine Transporteinrichtung, die Objekte an einem Seil befestigt von A
> nach B transportiert.


nein, das ist viel zu grob, Wikipedia sagt z.B. "Die Seilbahn ist ein
zu den Bahnen gehörendes Verkehrsmittel für den Personen- oder
Lastentransport."

Eine Scheibenrückholanlage ist eben kein Verkehrsmittel, und auch
keine "Bahn" im Sinne eines Verkehrsmittels.


> 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


schon klar.


> Transportmechanismus: Seilbahn


Quatsch


> Transportrichtung: bidirektional
> Transporteinrichtung: Wagen auf 2 Tragseilen
> Transportgut: Schiessscheibe


Quatsch IMHO. Man könnte so was zwar machen, ist aber eigentlich in
OSM nicht üblich.


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


Quatsch. Layer ist nicht für den Renderer da, sondern um in den Daten
bei übereinanderliegenden / kreuzenden Objekten auszudrücken, was oben
und was unten ist.


> Habe jetzt den "Sicherheitsbereich 2" eingezeichnet.
> Der überdeckt aber den Wald (zumindest wenn der Wald Mischwald ist).
> Ideal wäre, wenn der Renderer solche Flächen transparent anzeigt.


was ist das denn für eine "Fläche"? M.E. wäre eine boundary da
sinnvoller, und der Renderer sollte so was nur als Umriss bzw.
schraffiert darstellen, wenn überhaupt.


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


military ist doch nicht sinnvoll, wenn wir schon Sportschießen
sprechen, oder gehts doch um Militär?

m.E. irgendwas mit shooting_range für die Gesamtanlage, meinetwegen
leisure oder man_made (beides nicht sonderlich glücklich
zugegebenermaßen)


Gruß Martin

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

Re: [Talk-de] Das neue Taginfo

[M∡rtin Koppenhoefer]

Am 5. Oktober 2010 17:11 schrieb Jochen Topf :
> On Tue, Oct 05, 2010 at 04:30:03PM +0200, Peter Wendorff wrote:
>>  On 05.10.2010 16:00, Chris66 wrote:
>>> Wunsch: In dem Suchfeld soll auch nach Werten gesucht werden können.
>>> Also zB. gebe ich  "sauna" ein und möchte die zugehörigen Keys
>>> (amenity vs. leasure) angezeigt bekommen.
>> name nicht zu vergessen :D
>
> Und da liegt auch das Problem, warum ich das bisher nicht gemacht hab. Es ist
> nicht so einfach "mal schnell" 50 Millionen Tags zu durchsuchen. D.h.  ich
> brauche irgendeinen Index. Ein simpler Index ist einfach zu machen in Sqlite.
> Aber es dauert relativ lang, einen solchen Index aufzubauen. Und dann hab ich
> noch keine Substring-Suche, das ist aufwändiger und ich hab noch keine gute
> Idee, wie ich das machen soll. Und potentiell gibt es dann sehr viele Treffer,
> z.B. eben im name-Tag.


ja, den name-tag solltest Du vermutlich komplett ignorieren, genauso
wie ref und noch ein paar andere Kandidaten (evtl. note, description).
Die value-Suche wäre schon extrem wichtig, weil man sonst ja den Tag
schon kennen muss (dafür kann man dann tolle Statistiken und die Karte
mit der Verbreitung ansehen, wenn man den Tag erstmal gefunden hat).

Auch eine Karte, nachdem man einen bestimmten Wert gefunden hat, wäre
super (weiss nicht, wie aufwendig das ist), weil es einem ja nicht
hilft, wenn man eine Karte aller amenities angezeigt bekommt
(großteils flächig rot). Bei seltenen Keys ist es natürlich schon
ausreichend.

Insgesamt ein Super Mashup, sehr vielversprechend, aber bitte bitte
eine Value-suche/filter/karten ergänzen.

Gruß Martin

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

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

[Jan Tappenbeck]

Am 04.10.2010 11:06, schrieb olvagor:

Am 04.10.2010 10:58, schrieb M∡rtin Koppenhoefer:

tourism=lockbox


-1, ich finde nicht, dass Schließfächer tourismusbezogen sind.


Alternativvorschlag?


dimensions=20x50x50 (Breite x Höhe x Tiefe in cm)


Vielleicht könnte man sowas erfassen:

lockbox:20x50x50=20
lockbox:50x50x50=10

wobei der Wert die Anzahl der verfügbaren Fächer ist. Dann hätte man
auch gleich die Gesamtkapazität. Nur der Schlüssel sieht seltsam aus
aber was besseres fällt mir gerade nicht ein.


ist evtl. missverständlich, da der Tag nicht aussagt, ob es die
Gesamtanlage oder ein einzelnes Schließfach betrifft. Ausserdem werden
bei solchen Anlagen meist mehrere Dimensionen vorgehalten.


Das wäre damit erledigt.

Gruß,
Markus

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


Hi !

heute habe ich noch Schließfächer als Automat in Köln gesehen - da 
verschwinden die Gepäckstücke wohl irgendwo im Untergrund.


Irgendwie müßte man dann noch das vending unterbringen und dann gibt es 
noch eine kontaktteleofon nummer von x-y uhr und von y-x uhr !!!


Ideen !

Im Übrigen habe ich die bisherigen Daten schon einmal bei how-to-map 
hinterlegt - link gerade nicht zur hand.


gruß Jan :-)


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

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

[M∡rtin Koppenhoefer]

Am 6. Oktober 2010 09:16 schrieb Guenther Meyer :
> Am Dienstag 05 Oktober 2010, 22:29:30 schrieb Johannes Huesing:
>> olvagor  [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.


man würde dann ja auch 0.2 schreiben und nicht 0.20. Das x finde ich
auch nicht gut. Wenn man 3 Werte hat, sollte man m.E. auch 3 keys
haben. Also

locker:height:inner=0.5
locker:width:inner=0.2
locker:depth:inner=0.5


das erspart einem auch die unzähligen Verwechslungen von Höhe, Breite
und Tiefe, wenn man das einfach hintereinander schreibt.


Sobald man mal was sehr kleines oder großes beschreiben will,
empfiehlt sich allerdings sowieso ein Abweichen vom geliebten
OSM-Meter, von daher habe ich auch nichts gegen Angaben in cm. Mit
Einheit würde ich das dann allerdings eintragen.

Gruß Martin

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

Re: [Talk-de] Relation führt über area -> Lü cke

[M∡rtin Koppenhoefer]

Am 5. Oktober 2010 10:39 schrieb Peter Körner :
> Nun ich halte das auch bei Flüssen und Straßenflächen für Käse. Man kann von
> zwei Ankerpunkten auf einer geschlossenen Fläche eine Verbindungslinie
> darüber interpolieren, welche die Fläche nicht verlässt. Das ist eine
> Aufgabe des Renderers aber nicht des Mappers.


-1, wie willst Du denn die Richtung angeben? Irgendwie geht das
vielleicht, aber es braucht schon ein paar abstrakte Verrenkungen, die
man mit der gegenwärtigen, simplen und intuitiven Lösung eben nicht
braucht.

Gruß Martin

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

Re: [Talk-de] Relation runterladen?

[Carsten Gerlach]

Hallo,

Am Mittwoch 06 Oktober 2010 schrieb 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.

Wie Andre schon schrieb, man schont die API. Ich habe zum Beispiel alle 
Relationen mit admin_level=2 über die XAPI runtergeladen (zur Zeit ca. 700 
MB). Wenn ich jetzt alle diese Relationen nochmal über die API hole, lade ich 
vielleicht ca. 1 GB runter, weil ja viele Wege in zwei Relationen drin sind.
> 
> > 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.

Ich möchte gern jede Relation für sich als Bild rendern, und das kann z.B. 
mapgen.pl sehr gut.


Als generell andere Idee hatte ich schon, die 700-MB-Datei in eine Datenbank 
zu packen. Wenn ich dann "Gib mir Relation 1234 mit allen Knoten und Wegen als 
osm-Datei raus." sagen kann, wäre ich auch zufrieden. In der Datenbank 
(PostgreSQL mit Postgis) hab ich die Daten schon (nach der Anleitung im Wiki), 
bloß mit der Abfrage weiß ich noch nicht weiter. Oder kann man der lokalen 
Mapnik-Installation sagen, das er nur Relation XYZ rendern soll?

Gruß, Carsten

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

Re: [Talk-de] Mapnik rendert in 5 Minuten

[M∡rtin Koppenhoefer]

Am 5. Oktober 2010 08:23 schrieb Markus :
> Auf Vorträgen erzähle ich: "Mapnik rendert in 5 Minuten"
> und demonstriere das dann gleich life.
>
> Manchmal ist das aber nicht so.
> Gestern z.B. kam auf OpenStreetMap.org immer "more coming soon..."
> Und 12 Stunden später ist die Änderung immer noch nicht gerendert.


ach so, Du meinst die Mapnik Karten auf dem Server. Ich hatte schon
gedacht, Du renderst mit einem 486er ;-) Auf meinem "Billig-netbook"
rendert mapnik ein einigermaßen dichtes Gebiet (komplette Großstadt)
in einer Zoomstufe und mit 100 Megapixel in 1-2 Minuten, "normalgroße"
Bilder (z.B. 6 Megapixel) macht er in Sekunden. Lohnt sich echt, das
mal auszuprobieren, die Installation von Mapnik ist heutzutage ein
Kinderspiel - wenn man Ubuntu 10.04 verwendet und alles genau nach
Plan abarbeitet (div. Abhängigkeiten installieren und kompilieren).
Ansonsten sollte man allerdings nach wie vor fortgeschrittene
System-Kenntnisse haben. Wer z.B. Windows nutzt und denkt, man müsste
Computerexperte sein, um eine Parallelinstallation von Ubuntu
draufzuspielen (bzw. mit einem Livemodus = ohne Installation von CD
booten): einfach mal ausprobieren. Ist kinderleicht, solange es keine
Probleme gibt ;-)

Gruß Martin

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

Re: [Talk-de] Relation runterladen?

[Werner Hoch]

Hallo Rainer,

On Mittwoch, 6. Oktober 2010, Rainer Kluge wrote:
> 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.

Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert 
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.
 
> 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.

Das ist nur der Fall wenn du versuchst ein ganzes XML-File im Speicher 
zu halten. Mit einem Streaming-Parser muss man nur die nötigsten Infos 
im Speicher halten.
 
> 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.

Hier wäre wie vorher beschrieben ein Programm toll, das einen Stream in 
umgekehrter Reihenfolge erzeugt (Relationen, Ways, Nodes).

Grüße
Werner

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

Re: [Talk-de] Relation runterladen?

[Werner Hoch]

On Dienstag, 5. Oktober 2010, Carsten Gerlach wrote:
> Am Montag 04 Oktober 2010 schrieb Rainer Kluge:
> > In einer Zeit, als der Realtion Analyzer extrem langsam war, habe
> > ich mal ein Perl-Skript gebastelt, welches zu einer Relation-Id
> > den GPX-Track erzeugt.
> 
> Tolle Sache, gefällt mir, vorallem das verschachtelte Relationen
> komplett runtergeladen werden. :-)
> 
> 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?

Vor einiger Zeit gabs dazu mal einen Thread:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg71643.html
(lokaler Webserver, der OSM-ähnliche API-Zugriffe auf eine lokale OSM-
Datei zulässt). Der Webserver 

Im Angebot habe ich nur den Zugriff auf einzelne OSM-Objekte, keinen 
rekursiver Zugriff auf Objekte, wie für komplette Relationen 
erforderlich wäre.

Den Zugriff auf unkomprimierte osm-Dateien wollte ich auch mal einbauen, 
Im Moment würde mir das aber nichts bringen, weil ich nicht genug 
Plattenplatz für einen unkomprimierten planet habe.
 
> Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei
> ensteht.
> 
> Wäre super wenn das umsetzbar wäre. :-)

Hier sollte man den umgekehrten weg gehen. Relation zuerst aus der OSM-
Datei extrahieren und dann in GPX umwandeln.


Weitere Idee:
Ein Tool, dass die OSM-Datei in umgekehrter Form direkt aus einer bz2-
Datei streamt. (Relationen, Ways, Nodes)

Den Stream kann man dann mit einem Streaming-Parser (SAX) 
weiterverarbeiten ohne das man massenhaft Speicher benötigt.
Für alle Probleme bei denen man zuerst die Relationen benötigt muss man 
die Datei nur noch einmal parsen.

Link zu meinem Repo:
http://github.com/werner2101/python-osm

Grüße
Werner

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

Re: [Talk-de] AIO geht nicht auf 60Csx

[Christoph Wagner]

Am 5. Oktober 2010 15:50 schrieb Sven Geggus :
> Elchtreiber  wrote:
>
>> die gmapsupp.img von Bayern (30.9) funktioniert auf meinem Garmin nicht mehr.
>> Kann es sein, dass die Platte voll gelaufen ist?
>
> 90% belegt könnte temporär schon ein Problem sein.
>
>> Neuere Karten als vom 30.9 sind auch nicht mehr vorhanden.
>> Mag dort mal jemand schauen?
>
> hm, ich dachte Christoph kümmert sich drum :(

upsi - sorry.
Da hab ich wohl was zu lange vernachlässigt...

> ~/ # ll /osm/garmin/aio/logfiles/make_clean.log
> -rw-rw-r--+ 1 master osm 1.4K 2010-07-30 04:00 
> /osm/garmin/aio/logfiles/make_clean.log
>
> Ziemlich alt, das.
>
> Auf die Gefahr hin, dass ich da jetzt irgendwas kaputt mache habe ich
> nun einfach mal den make clean cronjob reaktiviert.


Nee das passt schon.
Wusste gar nicht, dass der aus war. Naja gut, jetzt läufts ja wieder.
Hoffe der erzeugt jetzt wieder alles hübsch. Sonst muss ich wohl mal
tiefer forschen, warum der hier schon tagelang abschmiert.
Im Moment scheint er ja zu laufen.

Das make clean löscht alles, was älter als 6 Tage ist. Ist natürlich
blöde, wenn der seit 6 Tagen keine neue Map mehr erzeugt hat.

Na mal schaun, obs heute klappt. *zitter*

Grüße
Christoph

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

Re: [Talk-de] Relation runterladen?

[Andre Joost]

Rainer Kluge schrieb:

> 
> 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.

Man würde die api bzw den Relation Analyzer schonen, wenn man in einem
Rutsch alle Wanderwege, Rad- oder Busrouten; Grenzen oder
Hochspannungsleitungen seines Bundeslandes als einzelne gpx haben
möchte. Xapi und osmosis bieten da ja leider nur eingeschränkte
Unterstützung.

> 
>> 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.

Anwendungsfall wäre z.B.Rendern als lokale transparente Tiles, die man
als Layer separat in OL einblenden kann. GPX ist da ab einem gewissen
Datenvolumen zu langsam.

Die OSM-Ausgabe ist dagegen ziemlich einfach. Gpx ist ja auch XML; halt
mit anderen keys als OSM. Man müsste nur die tags der Objekte zusätzlich
zwischenspeichern.

Das ganze lässt sich natürlich auch in osmosis einbauen. Ich weiß nur
nicht, ob es da zwischen java und perl (oder ggf C) nenneswerte
Performancevorteile bei der Verarbeitung großer Datenmengen geben würde.
Hat da jemand mal Vergleichstest gemacht?

Bietet denn das neue Binärformat der Geofabrik-Extrakte hier Vorteile
bei der Verarbeitung?

-- 
Gruß,
André Joost


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

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

[Christoph Wagner]

Am 6. Oktober 2010 16:52 schrieb Sven Geggus :
> Christoph Wagner  wrote:
>
>> Wie häufig werden bereits existierende Informationen wieder verändert?
>> Gibt es Unterschiede zwischen den Tags?
>
> Full Planet dump geeignet in eine DB einlesen?
>
> Nur so eine Idee.
>

Hmm, habs schon befürchtet.
Hat jemand ne Ahnung wie groß das Ding in ner Datenbank ist?
Müsste ich mir bestimmt ne neue Festplatte holen...

Was gibts so für Möglichkeiten/Tools, um das überhaupt in ne DB zu
bekommen? Geht da was mit osmosis?
Hat das nicht schon jemand mal gemacht und braucht jetzt nur noch ne
Query loszulassen?
Die würde ich dann auch basteln helfen, wenn ich die Tabellenstruktur kenne.

Danke
Christoph

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

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

[Sven Geggus]

Christoph Wagner  wrote:

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

Full Planet dump geeignet in eine DB einlesen?

Nur so eine Idee.

Gruss

Sven

-- 
"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] Zeilenumbruch in "name"?

[Sven Geggus]

Guenther Meyer  wrote:

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

Ich bin mir ziemlich sicher, dass ein cut and paste eines solchen von einem
Webbrowser klappen könnte.

Sven

-- 
"Software is like sex; it's better when it's free"
  (Linus Torvalds)

/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] Aerowest: Bildflugwünsche und -tarif e 2010

[Gehling Marc]

Hallo Tobias,

war gerade bei Aerowest und habe mit Benfer gesprochen. Mache jetzt noch den 
OSM-Stand und könnte morgen etwas mehr schreiben.

Marc

Am 06.10.2010 um 16:05 schrieb 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


___
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?

[Sven Geggus]

Carsten Schwede  wrote:

> 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.

AFAIK ja!

Sven

-- 
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/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

[Peter Wendorff]

 On 06.10.2010 13:17, Micha Ruh wrote:

Ich habe die Schiessstände nach folgendem Schema gemapped.

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

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

Funktioniert gut für 300m und 30m.

finde ich gar nicht schlecht,
ich würde aber eventuell auf die shooting range zusätzlich zu
shooting=range noch
sport=shooting
taggen.

Gruß
Peter


Gruëss, Micha
___
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

[Peter Wendorff]

 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] Intergeo

[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] Zeilenumbruch in "name"?

[Peter Wendorff]

 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] Zeilenumbruch in "name"?

[Peter Wendorff]

 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"?

[Peter Wendorff]

 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"?

[Peter Wendorff]

 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.477066&lon=11.97303&zoom=18&layers=M 
"
SO ist wohl nicht glücklich.

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

Das Leerzeichen als Kennzeichen eines möglichen Umbruchs ist definitiv zu wenig!
Z.B. "Haus33: Spielehaus" - besser wäre "Haus 33:Spielehaus"
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   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] Relation runterladen?

[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

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

[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] Zeilenumbruch in "name"?

[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.477066&lon=11.97303&zoom=18&layers=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] OSM Statistik gesucht - Editierfrequenz von Tags

[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"?

[Guenther Meyer]

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

Re: [Talk-de] Zeilenumbruch in "name"?

[Markus]

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  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  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"?

[Elstermann, Mike]

>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.477066&lon=11.97303&zoom=18&layers=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"?

[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"?

[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.477066&lon=11.97303&zoom=18&layers=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] All In One - Flughafen Poi / airoway vs. amenity?

[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"?

[Guenther Meyer]

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.477066&lon=11.97303&zoom=18&layers=M
> " SO ist wohl nicht glücklich.
> 
> Bsp. 2: Und SO auch nicht:
> http://www.openstreetmap.org/?lat=51.47707&lon=11.97303&zoom=17&layers=O

ich wusste, dass es reale Bespiele gibt ;-)


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

Ein Leerzeichen, bei dem nicht umgebrochen werden darf, gibt's in Unicode 
unter U+00A0 (in HTML bekannt als  ).
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] Zeilenumbruch in "name"?

[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.477066&lon=11.97303&zoom=18&layers=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] All In One - Flughafen Poi / airoway vs. amenity?

[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"?

[Guenther Meyer]

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] Zeilenumbruch in "name"?

[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.477066&lon=11.97303&zoom=18&layers=M "
SO ist wohl nicht glücklich.

Bsp. 2: Und SO auch nicht: 
http://www.openstreetmap.org/?lat=51.47707&lon=11.97303&zoom=17&layers=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. "Haus33: Spielehaus" - besser wäre "Haus 33:Spielehaus"

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] Schiessstand Schweiz

[Markus]

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] Schiessstand Schweiz

[Micha Ruh]

Ich habe die Schiessstände nach folgendem Schema gemapped.

http://www.openstreetmap.org/?lat=47.652563&lon=8.830605&zoom=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] Das neue Taginfo

[Sebastian Klein]

Jochen Topf wrote:

Das ist ein halb-breites Leerzeichen ( ). 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] Zeilenumbruch in "name"?

[Peter Wendorff]

 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

[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"?

[Guenther Meyer]

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] Zeilenumbruch in "name"?

[Peter Wendorff]

 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] Schiessstand Schweiz

[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"?

[Elstermann, Mike]

> 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  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.477066&lon=11.97303&zoom=18&layers=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] All In One - Flughafen Poi / airoway vs. amenity?

[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"?

[Sven Geggus]

Elstermann, Mike  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.477066&lon=11.97303&zoom=18&layers=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?

[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

[Talk-de] Zeilenumbruch in "name"?

[Elstermann, Mike]

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.477066&lon=11.97303&zoom=18&layers=M

Danke, mikeE63.

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

Re: [Talk-de] Schiessstand Schweiz

[Peter Wendorff]

 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

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

[Sven Geggus]

Florian Lohoff  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

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

[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] Schiessstand Schweiz

[Markus]

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

Re: [Talk-de] Schiessstand Schweiz

[Markus]

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.524031&lon=8.431179&zoom=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] öffentl. Schließfächer

[Guenther Meyer]

Am Dienstag 05 Oktober 2010, 22:29:30 schrieb Johannes Huesing:
> olvagor  [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