Re: [Talk-de] autobug update

[Stefan Dettenhofer (StefanDausR)]

Torsten Breda schrieb:
>> ich hätte noch einen Vorschlag zu den
>> Gemeinde-/(Land-)Kreis-Bezeichnungen (is_in) etc.
>> Warum Verwenden wir nicht die schon europaweit existierenden
>> NUTS/LAU-Schlüssel?
>> http://de.wikipedia.org/wiki/NUTS
>> Die Listen kann man sich frei herunterladen und dann hat man kein
>> Problem mit verschiedenen (nicht-amtlichen) Schreibweisen.
>> 
> +1
>
> Ich weiß noch nicht genau, wie man es genau anwenden sollte, aber
> diese Liste finde ich irgendwie sympatisch (in dem Rahmen, indem man
> eine Excel-Tabelle sympatisch finden kann). Auf jeden Fall
> sympatischer, als diese langen is_in Zeichenfolgen, in denen sich
> Redundanz und Fehlerteufel um die Vorherrschaft streiten.
>
>   
Hier sehe ich auch das große Problem, dass man nie eine einheitliche 
Schreibweise vorfinden wird
> Warum überhaupt muss in dem Tag meines Ortes stehen, in welchem Kreis
> der Ort ist? Reicht das nicht bei der Stadt, die beim Ort im is_in
> steht?
>   
Ich hatte das (bisher) eigentlich auch als Baumstruktur gesehen, also
Dorf is_in Gemeinde
Gemeinde is_in Kreis
Kreis is_in (Bundes-)Land
Land is_in Staat
usw.

Damit wurde schon mal eine gewisse fehlerhafte Redundanz wegfallen. 
Wobei es immer noch Probleme mit gleichnamigen Orten gäbe.

Haher bin ich eher der freund eines eindeutigen (und offiziell 
anerkannten) Schlüssels. Die Gemeindekennzahl wäre da auch möglich, ist 
aber nur in Deutschland gebräuchlich. Daher kam ich auf die NUTS/LAU.
> Ich gebe zu, ich bin kein großer Freund von Relationen, jedoch sind
> genau solche Zusammenhänge super in Relationen zu erfassen.
>   
Das wäre sicher möglich, nur sehe ich dann das Problem, was man in die 
Relation aufnimmt: Nur den place= oder auch die Gemeindegrenze oder 
gleich alle Elemente der Gemeinde?
Letzteres wäre natürlich nicht sinnvoll zu handeln! So große Relationen 
sind unbedingt zu vermeiden.

Wenn man das Problem mit Relationen löst, dann könnte man aber auch 
gleich auf den NUTS-Schlüssel verzichten bzw. diesen nur als Zusatzinfo 
an die Relation hängen.


Ich denke der NUTS/LAU-Schlüssel macht nur Sinn, wenn man den für jedes 
relevante Element (also insbesondere place=) vergibt. Der ist ja im 
Prinzip genauso hierarchisch aufgebaut, wie die momentane 
ausgeschriebene Textform in is_in.

> Wer also schreibt mal was zum NEUEN Key:NUTS bzw. Key:NUTSLAU ??? Ich
> denke, derjenige wird Unterstützung bekommen, da es jedem einleuchten
> sollte, dass wir uns dadurch jede Menge Arbeit ersparen.
>
>   
Mal sehen, was die Diskussion hier noch ergibt (und meine Zeit zulässt)

> Mit Gruß
> Torsten, der erst mal nichts mehr an den antiquierten is_in-Tags editieren 
> wird.
>
>   
Gruß,
Stefan (StefanDausR)



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

Re: [Talk-de] Druchfahrtshöhe Brücke

[Stefan Dettenhofer (StefanDausR)]

Halllo Jan


> wo hinterlege ich denn die Durchfahrtshöhe einer Brücke ???
>
> Das Attribut ist interessant für die durchführende Straße - damit hat 
> das BRIDGE-Attribut aber nichts mit zu tunt ?
>   
Eigentlich kannst Du das nur sinnvoll an das Teilstück unter der Brücke 
setzten. Dazu musst Du halt den Weg auftrennen.

Gruß,
Stefan


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

Re: [Talk-de] Wanderweg - Relation

[Stefan Dettenhofer (StefanDausR)]

Hallo,
> Schau dir mal das tool  
> http://betaplace.emaitie.de/webapps.relation-analyzer/ an. Hier kann ich  
> relationen suchen. Hier kann ich relationen kontrollieren.
Das kannte ich noch gar nicht! Tolles Teil, aber...
> Da ist es schon richtig wenn man mehrere fehlerlose relationen hat. Die  
> sollte man aber dann - hab ich schon mal hier gesehen  
> http://wiki.openstreetmap.org/index.php/Radverkehrsnetz_NRW die relation  
> 33216 - als superrelation zusammenfassen.
... es gann leider mir den "Superrelationen" noch nichts anfangen, da 
stürzt es ab!

Noch was zu den "Superrelationen":
Ich verstehe darunter einfach eine Zusammenfassung mehrerer (nicht zu 
vieler!) kleinerer Teilrelationen zu einem ganzen Weg.

Wie soll sie "Superrelation" getaggt werden? Als network oder im selben 
Typ wie die Einzelteile?

Ich habe einen Wanderweg, der explizit aus einzelnen Etappen besteht. 
Die Etappen habe ich in Relationen zusammengefasst (route=hiking) und 
der Superrelation (49759) auch route=hiking gegeben, da sie ja auch ein 
realer Wanderweg ist.

Gruß,
Stefan


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

Re: [Talk-de] Wanderweg - Relation

[Stefan Dettenhofer (StefanDausR)]

Hallo Willi,


>> Wie soll sie "Superrelation" getaggt werden? Als network oder im selben 
>> Typ wie die Einzelteile?
>> 
>
>
> hier http://www.openstreetmap.org/browse/relation/33216/history schon mal  
> ein Beispiel von anderen OSMlern.
>
>   

Ich weiß aber nicht, ob in meinem Beispiel
http://www.openstreetmap.org/browse/relation/49759/history
type = network richtig ist, da es sich ja eigentlich nur um einen Weg 
handelt und nicht um ein ganzes Netzwerk!

Wenn ja, dann müsste ich es so machen, oder?
name = Jurasteig
type = network
route = hiking
network = Jurasteig
ref = Jurasteig  (?)


Gruß,
Stefan



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

Re: [Talk-de] Wanderweg - Relation

[Stefan Dettenhofer (StefanDausR)]

Hallo Willi,

> Am 12.11.2008, 08:06 Uhr, schrieb Stefan Dettenhofer (StefanDausR)  
> <[EMAIL PROTECTED]>:
>
>   
>> Wenn ja, dann müsste ich es so machen, oder?
>> name = Jurasteig
>> type = network
>> route = hiking
>> network = Jurasteig
>> ref = Jurasteig  (?)
>> 
>
> Hallo Stefan
>
> hier http://wiki.openstreetmap.org/index.php/DE:Relation:route ist es noch  
> besser beschrieben.
>
>   

Hier ist nur die "normale" Relation beschrieben, aber nicht die 
übergeordnete "Superrelation"!

Macht es Sinn, zwischen Wanderweg und Spazierweg zu unterscheiden? Dann 
würde ich nämlich folgendes vorschlagen:

Wanderweg-Relation:
typeroute
route   hiking

(...)

Spazierweg-Relation:
typeroute
route   foot

(...)

"Super-Relation", Zusammenfassung mehrerer gleichartiger 
Routenabschnitte (besteht i.A. nur aus Relationen):
typenetwork
route   foot / hiking / ...

(...)

Stefan



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

Re: [Talk-de] Wanderweg - Relation

[Stefan Dettenhofer (StefanDausR)]

Hallo Markus,
>> Wanderweg-Relation:
>> type route
>> route hiking
>> 
>
>   
>> Spazierweg-Relation:
>> type route
>> route foot
>> 
>
> Und was wären die Unterscheidungsmerkmale?
>
>   

Ich weiß eben auch noch nicht, ob es Sinn macht, zwischen 
"Turnschuhwegen" in der Ebene und Wanderwegen im Gebirge zu unterscheiden.
Fakt ist nur, dass sowohl foot als auch hiking in der OSM-DB vorkommt.
Entweder vereinheitlicht man das, also alles als foot oder hiking oder 
man macht einen Unterschied.

Gruß,
Stefan


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

Re: [Talk-de] OSM soll noch 2008 ganz Deutschland umfassen?

[Stefan Dettenhofer (StefanDausR)]

Hallo,

André Reichelt schrieb:
> Das weiss ich doch schon alles. Nur dummerweise sieht man nicht, was 
> man da gerade aufzeichnet und das stört mich. 

Hm, vielleicht baue ich das in Koord mal ein... Du kannst aber 
inzwischen auch schon unabhängig von GoPal Tracks aufzeichnen und POIs 
erfassen. Hier
http://forum.pocketnavigation.de/thread.php?postid=2115770#post2115770
habe ich ein Koord-Menü zur Erfassung von maxspeed über NaviPOWM gelegt.


>
> Ich finde das doch sehr umständlich. Man hat immer in einer Hand das
> Navi, da ist das etwas blöd. Das Medion hat doch ein eingebautes Mikro.
> Gibt es denn keine kompatible Software, mit der man gleichzeitig
> Trackpunkte aufzeichnen und ton Aufnehmen kann? Das wäre ein Segen!
>
>   
Ich habe bis jetzt noch keine Möglichkeit gefunden das Mikro 
anzusteuern, aber auch noch nicht genauer gesucht!

Gruß,
Stefan


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

Re: [Talk-de] Herscht Konsens zur Darstellung von Gren zen über Relationen?

[Stefan Dettenhofer (StefanDausR)]

Hallo Jochen,
> Ein wichtiger Punkt ist dabei noch der Umgang mit größeren und komplexen
> Gebilden, die z.B. Enklaven haben. Frederik hat gerade einen Vorschlag
> ins Wiki gestellt, wie bestehende Multipolygon-Relations erweitert
> werden können, damit sie auch mit sowas zurecht kommen:
> http://wiki.openstreetmap.org/index.php/Relation:multipolygon#Suggestion_for_advanced_multipolygons
>
> Diese Multipolygon-Relations können wir auch für Grenzen verwenden.
> Damit sollten sich alle vorkommenden Fälle lösen lassen.
>
>   

ich finde den Vorschlag gut!
Wie wird aber garantiert, dass die Elemente in der Datenbank geordnet 
bleiben? Ich dachte, dass bisher nicht sichergestellt ist, dass die 
Elemente jedesmal in der selber Reihenfolge wieder ausgespielt werden.

Gruß,
Stefan


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

Re: [Talk-de] Maxspeed Karte Update ?

[Stefan Dettenhofer (StefanDausR)]

Hallo Henry,


[EMAIL PROTECTED] schrieb:
> Hi,
>
> ich finde die Maxspeed-Karte
>  
> http://wince.dentro.info/koord/osm/KosmosMap.htm?zoom=11&lat=6584584.24356&lon=680129.86234&layers=BT
>
> ziemlich Klasse,

schön, dass sie Dir gefällt!

> allerdings frage ich mich wann da ein Update kommt.
ok, ich wollte gerade ein Update anwerfen, aber die OSMXAPI wollte nicht...

>
> Denn unter
>
> http://www.openstreetmap.org/?lat=50.892909&lon=6.126189&zoom=18&layers=B000FTT
>
> habe ich letzte Woche(04.11.08) Daten geändert, leider sehe ich noch 
> kein Update.
>
> Daher die Frage wie oft wird die Karte erneuert ?

Ich mache es manuell in unregelmäßigen Abständen. Das größte Problem ist 
eigentlich, dass das Übertragen der tiles auf meinen Server so lange 
dauert...
>
> Liege ich richtig mit der Vermutung, das die Karte mit kosmos Erzeugt 
> wird?

ja

> Kann man selber rechnen ?

ja, hier
http://wiki.openstreetmap.org/index.php/MaxSpeed_Overlay_Kosmos_Rules
sind die Rendering-Rules

> Kann man die für andere Rechnen ?
> Auch wäre eine Legende für die verwendeten Farben nett.
hier
http://forum.pocketnavigation.de/tid943-sid.htm
findest Du was dazu!

Gruß,
Stefan



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

Re: [Talk-de] Maxspeed Karte Update ?

[Stefan Dettenhofer (StefanDausR)]

Hallo Wolfgang,

meine maxspeed-Karte hat transparenten Hintergrund und wird über die 
vorhandenen [EMAIL PROTECTED] gelegt!
Ich rendere momentan einen Bereich von E005-E015 und N35-N55. Da ist 
Österreich fast vollständig mit d'rin (ok Wien fehlt - ich werde es mir 
merken!)
Momentan übertrage ich gerade die Daten bis zur Zoomstufe 13 auf den 
Server. Level 14 wird noch gerendert.

Gruß,
Stefan

Wolfgang W. Wasserburger schrieb:
> gefällt mir auch, aber schön wäre noch, wenn der Überleger transparenten
> Hintergrund hätte und es das ganze auch noch für Österreich gäbe ;-)
>
> lg  von der Mazzesinsel
>
> Wolfgang
>
>
>   



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

Re: [Talk-de] Abstufung tracktype

[Stefan Dettenhofer (StefanDausR)]

Hallo,

ich denke auch, dass zu viele Abstufungen nichts bringen und man sich 
eher auf wenige einigen sollte und diese mit klaren Regeln bzw. 
Beispielen festlegt:
Ich finde eigentlich die Beschreibung von tracktype in JOSM recht gut 
und auch nachvollziehbar:
tracktype=1 -> asphaltiert
tracktype=2 -> geschottert
tracktype=3 -> befestigt
tracktype=4 -> weniger befestigt
tracktype=5 -> unbefestigt

wobei man eigentlich 3 und 4 auch zusammenfassen könnte.

Ich denke das wichtigste bei einem track ist, dass ein 2-spuriges 
Fahrzeug da fahren könnte und (im Notfall) auch kann (Notarzt, 
Feuerwehr, ...), egal ob es erlaubt ist oder nicht.

Ob es wirklich Sinn macht die Beschaffenheit noch genauer zu definieren 
mag ich bezweifeln, denn spätestens nach einem starken regen schaut es 
schon ganz anders aus...


Gruß,
Stefan


Sebastian Hohmann schrieb:
> Das Tagging scheint allgemein eher nach Gefühl zu gehen, als nach klaren 
> Definitionen. Allerdings gerade bei der Wegbeschaffenheit wohl zu Recht. 
> Während man meistens noch entscheiden kann ob ein Weg versiegelt ist 
> oder nicht (surface=paved/unpaved) und vielleicht auch noch das Material 
> angeben kann (surface_material=cobblestone/paving_stones/grit/gravel/..) 
> gestaltet sich das Zählen von Schlaglöchern wohl eher schwierig.
>
> surface=paved
> surface_material=cobblestone
> smoothness=intermediate
>
> Die Idee bei smoothness ist halt die Laufruhe grob anzugeben. Da die 
> Definition nach der Nutzbarkeit für verschiedene Fortbewegungsarten 
> schon recht schwammig ist (kommt ja auf den Rennradfahrer an wo er sich 
> wohl fühlt), geht es nunmal nicht genauer. Ich persönlich benutze da 
> auch nur 6 statt 8 Werten:
>
> - excellent, keinerlei Unebenheiten beim Befahren spürbar -> 
> Inline-Skater sollten sich wohl fühlen
> - good, hier und da mal etwas uneben, aber nicht stark beeinträchtigend 
> -> Rennradfahrer kommen gut vorran
> - intermediate, spürbare Schlaglöcher oder Unebenheiten, die die 
> Geschwindigkeit schon einschränken -> wer mit dem Citybike unterwegs ist 
> und es nicht eilig hat ist zufrieden
> - bad, tiefe Schlaglöcher und Bodenwellen -> durchschnittliche Autos 
> kommen noch durch, aber hier ist schon langsamfahren angesagt
> - horrible, kleine und größere Steine, Schlaglöcher und Unebenheiten die 
> gekonnt durchfahren werden sollten -> Mountainbikern und Geländewagen 
> macht es hier Spaß
> - impassable, große Steine, tiefe Rinnen -> für normale Fahrzeuge ist 
> hier Schluss (Fußgänger und Biker mit entsprechendem Können kommen 
> sowieso überall durch)
>
> Sicherlich ist das Ganze relativ subjektiv und mehr Werte machen es 
> sicher noch subjektiver, da die Unterscheidung zwischen den Einzelnen 
> schwerer wird. Aber wie kann man es wirklich objektiv angeben? 
> Schlaglöcher und Bodenwellen zählen? Auf den nächsten Regen warten um 
> herauszufinden wie sich der Belag dabei verhält? Und wie ist es wenn 
> Schnee liegt?
>
> Ich bin immer offen für neue Vorschläge, aber ich fürchte etwas 
> subjektiv und ungenau bleibt es dabei immer.
>
> Gruß
>
>   


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

Re: [Talk-de] Hausnummern mit Buchstaben

[Stefan Dettenhofer (StefanDausR)]

Jochen Topf schrieb:
>
> Wir führen neben addr:interpolation=all|odd|even noch
> addr:interpolation=xyz ein (für xyz müssen wir noch einen Namen finden).
>   
wie wärs mit

addr:interpolation=string oder meinetwegen auch addr:interpolation=
char


Stefan


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

Re: [Talk-de] Maxspeed Karte Update ?

[Stefan Dettenhofer (StefanDausR)]

Hallo zusammen,

[EMAIL PROTECTED] schrieb:
> Hi,
>
> ich finde die Maxspeed-Karte
>  
> http://wince.dentro.info/koord/osm/KosmosMap.htm?zoom=11&lat=6584584.24356&lon=680129.86234&layers=BT
>
> ziemlich Klasse, allerdings frage ich mich wann da ein Update kommt.
>
die maxspeed-Karte habe ich nun wieder neu rechnen lassen (Datenstand 
13.11.2008). Zoomlevel 14 wird gerade noch übertragen.

Zur Info:
Zoomlevel 0-12 sind gemeinsam 50.589 Dateien mit zusammen 85,3 MB
Zoomlevel 13 sind 149.766 Dateien mit zusammen 209 MB
Zoomlevel 14 sind 596.448 Dateien mit zusammen 789 MB

Daher rechne ich die Daten nicht so häufig neu...

Gruß,
Stefan

P.S.: der Permalink funktioniert nicht!


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

Re: [Talk-de] Karlsruhe Schema => volle Infos?

[Stefan Dettenhofer (StefanDausR)]

Hallo Sebastian,

ich denke auch, dass auf kurz oder lang (fast) jede Straße zu einer 
Relation werden muss! Je mehr Attribute erfasst werden, in desto mehr 
kleine Weg-Abschnitte muss sie zerstückelt werden. Alleine das taggen 
von maxspeed generiert sehr viele Wegabschnitte.
Die einzige Möglichkeit diese Abschnitte wieder zusammenzufassen ist 
eine Relation, die den Namen und/oder die ref der Straße enthält!

Sebastian Hohmann schrieb:
> Wenn man sich jetzt noch auf eine Relation einigen könnte (und im Wiki 
> dokumentieren), würde ich das in Zukunft auch so machen, denn diese 
> Redundanz (am besten noch mit Stadt und PLZ) nervt doch ziemlich.
>
>   
Bei der PLZ ist es schon schwieriger! Es gibt etliche Straßen, die zu 
zwei (oder mehreren?) PLZ-Gebieten gehören. Gleiches gilt für die Stadt 
bzw. auch für den Straßennamen, wenn es sich nicht nur um 
innerstädtische Straßen handelt!

Nehmen wir z.B. eine Kreisstraße, die durch mehrere Dörfer führt:
Das einzige Attribut, das über die ganze Länge konstant ist, ist die 
ref, die man in die Relation packen kann! Es ändern sich sowohl der 
Straßenname als auch die PLZ und sonst so einiges.
Natürlich könnte man jetzt mit mehreren Relationsebenen arbeiten, aber 
ich denke das wird für den Normaluser zu kompliziert!

Daher mein Vorschlag:
Man packt nur das / die Attribut(e) in die Straßenrelation, die auch auf 
der gesamten Länge konstant sind. Das sind sozusagen die Defaultwerte 
der beinhalteten Elemente.
Alle anderen Attribute müssen an das Element selber!

Gruß,
Stefan


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

Re: [Talk-de] Inkonsistenz bei Netzwerken für Rad- u nd Wanderwege in Relationen

[Stefan Dettenhofer (StefanDausR)]

Sven Anders schrieb:
> Am Montag, 17. November 2008 09:03 schrieb Raphael Studer:
>   
>> On Mon, Nov 17, 2008 at 8:01 AM, Sven Anders <[EMAIL PROTECTED]> wrote:
>> 
>>> Am Sonntag, 16. November 2008 17:59 schrieb Brunner, Armin:
>>>   
 Also statt gar nichts oder beispielsweise:
 rcn=yes
 rcn_ref=xxx

 Wäre nach meiner Ansicht korrekt:
 network=rcn
 ref=xxx

 Was haltet Ihr von dem Vorschlag?
 
>>> Was machst du wenn ein Weg gleichzeitig ein Regonaler Radweg und ein
>>> Nationaler Radweg ist?
>>>
>>> z.B. in Hamburg der Radweg Hamburg Bremen und die Radroute 10 liegen auf
>>> dem selben Webabschnitt.
>>>   
>> Dann kommt der Weg in beide Relationen.
>> In die Radweg Relation(network=rcn) und in die Wanderrelation (network=rwn)
>> 
>
> Gut bei Relationen kann man das machen, ich tagge aber im Moment eher die 
> Ways 
> selber, und da geht das nicht.
>
>
>   
aber network= gehört nur an eine Relation und hat am way nichts zu 
suchen! Gleiches gilt auch für ref, wenn damit eine Wegbezeichnung 
gemeint ist und es mehrere davon gibt!

Gruß,
Stefan


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

Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten

[Stefan Dettenhofer (StefanDausR)]

Tobias Wendorff schrieb:
> Jochen Topf schrieb:
>   
>> de:amtlicher_gemeindeschluessel=[AGS5]
>> 
>
> Wollt ihr das echt so nennen? Ich würde da etwas Internationaleres
> verwenden, z.B.
>
> communal_code oder communal_reference oder communal_key etc.
>
> Ich habe glaube ich schon mal community_index in einem Fachbuch
> gelesen.
>
>   
Warum nicht? Das ist doch ein guter Ansatz! de:AGS5 ist doch eindeutig! 
Man kann den Schlüssel auch jederzeit mit Hilfe der NUTS/LAU-Tabellen in 
die europäische Form umwandeln. Siehe auch meine Beiträge dazu weiter oben!

Gruß,
Stefan


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

Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten

[Stefan Dettenhofer (StefanDausR)]

Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Warum nicht? Das ist doch ein guter Ansatz! de:AGS5 ist doch eindeutig! 
>> Man kann den Schlüssel auch jederzeit mit Hilfe der NUTS/LAU-Tabellen in 
>> die europäische Form umwandeln. Siehe auch meine Beiträge dazu weiter oben!
>> 
>
> Ganz einfach: Weil OSM nicht nur von Deutschen verwendet wird. Wenn
> irgendjemand aus dem Ausland irgendwann einen Router oder ein Tool
> schreibt, muss er wissen, dass wir in Deutschland
> "de:amtlicher_gemeindeschluessel" verwenden.
>
> Und wenn die ehemalige GKZ in 5 Jahren wieder in etwas Anderes,
> wie "digitale Gemeindebezeichnung DGBz" umbenannt werden würde,
> müsste die Datenbank wieder verändert werden - dies wäre zwar
> simpel, aber ...
>
>   
ich sehe jetzt das Problem nicht! Wir können doch froh sein, ein 
komplettes und vollständiges Datenmaterial zu bekommen! Wie ich schon 
geschrieben habe, kann man das ja -wenn mann will- jederzeit in das 
EU-weite Format umcodieren. Das kann per script laufen, also

"de:amtlicher_gemeindeschluessel"
"eu:NUTS/LAU"

Von einem weltweit gültigen Schlüsselsystem weiß ich nichts. Also nehmen wir 
doch das was es schon gibt.

Und wer weiß jetzt schon, was in 5 Jahren ist?

Gruß,
Stefan 



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

Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten

[Stefan Dettenhofer (StefanDausR)]

Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> ich sehe jetzt das Problem nicht! Wir können doch froh sein, ein 
>> komplettes und vollständiges Datenmaterial zu bekommen!
>> 
>
> Von komplett und vollständig möchte ich erst sprechen, wenn ich die
> Daten und den Umfang sichten konnte.
>   
hier
http://tools.geofabrik.de/osmi/?view=kreisgrenzen
kannst Du sie doch sichten...



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

Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten

[Stefan Dettenhofer (StefanDausR)]

Dominik Spies schrieb:
> Apropo Gemarkungen:
> Wie sind denn Gemeindegrenzen (und Gemarkungen - aber die müssen ja
> nicht immer übereinstimmen) eigtl. festgelegt?
> Sind das immer geordnete Mengen von Vermessungspunkten? Gibt es für
> jeden solchen Punkt Kennzeichen ("Grenzstein")?
> Sind die in irgendwelchen offizielen "Grenzurkunden" oder so
> veröffentlicht? Als echte Vermessungsdaten, nicht als
> Übersichtskarte..
> Oder sind diese Daten nur bei den Vermessungsämtern und nur gegen
> dicke Kohle zu haben..?
>
>   

Ich weiß nur, wie die in der DFK in Bayern definiert sind. Da sind es 
Attribute an der Flurstücksgrenze. Sie sind also parzellengenau erfasst!
Die Linien der Flurstücksgrenzen wiederum sind (geradlinige) 
Verbindungen zwischen Grenzpunken. Das müssen aber nicht unbedingt 
"Grenzsteine" sein.

Gruß,
Stefan


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

Re: [Talk-de] API 0.6

[Stefan Dettenhofer (StefanDausR)]

Frederik Ramm schrieb:
> Wenn jemand in einem Forum mitliest, in dem das interessant sein könnte, 
> gern auch dorthin übernehmen.
>
>   
habe es hier
http://forum.pocketnavigation.de/thread.php?threadid=1123574
veröffentlicht!


Stefan


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

Re: [Talk-de] Luftbilder LVA Bayern

[Stefan Dettenhofer (StefanDausR)]

Hallo Markus,

Markus schrieb:
> Zu meiner Anfrage bei der Bayrischen Regierung gibt es nun eine 
> Entscheidung:
>
> Bayern stellt als *Pilotprojekt mit OSM* die Luftbilder in 2-m-Auflösung 
> für den gesamten Regierungsbezirk Oberpfalz (10.000 m²) zur Verfügung. 
> Damit soll eine mögliche künftige Zusammenarbeit des 
> Landesvermessungsamtes Bayern mit OSM geprüft werden.
> Bei Erfolg soll seitens der Bayr. Regierung geprüft werden, ob die 
> Zusammenarbeit auch auf Bundesebene ausgeweitet werden kann.
>
> Die Nutzungswvereinbarung wird wahrscheinlich zum OSM-Wochenende 
> vorliegen, die Daten sollen nächste Woche übermittelt werden.
>
> Ich werde berichten.
>
> Gruss, Markus
>   

toll, dass Du das geschafft hast!
Die 2m-Auflösung reicht zumindest für Straßen und Wälder völlig aus! bei 
Gebäuden wird es schon knapp...
Die Daten kann man sich auch schon mal online in Bayern-Viewer ansehen:
http://www.geodaten.bayern.de/BayernViewer/index.cgi

In welcher Form sollen den die Daten zur Verfügung gestellt werden? 
Meines Wissens sind das ja Orthofotos, die ins GK-System eingepasst sind.
Zumindest nutze ich (u.a.) diese Daten selber in einem kommerziellen 
(selbstprogrammierten) System.

Wenn die Daten zum abdigitalisieren freigegeben werden, dann wird man 
sie nicht ohne weiteres in JOSM hinterlegen können, oder?

Gruß,
Stefan


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

Re: [Talk-de] OSM und OpenLayer

[Stefan Dettenhofer (StefanDausR)]

Hallo Markus,

bei mir klappt es wunderbar!
Vielleicht hast Du noch alte Daten im Cache?

Gruß,
Stefan

Markus schrieb:
> Hilfe! - OL funktioniert nicht mehr...!
>
> Da hat endlich alles bestens funktioniert,
> Linien und Punkte wurden angezeigt,
> Texte und Fotos als Popup,
>
> und jetzt ist alles weg:
> http://www.lau-net.de/baerlocher/osm/Simmelsdorf.html
> http://www.gnu.franken.de/ke/trips/2008/20081123-signalstein.html
>
> Ich habe nichts geändert...
>
> Woran könnte das liegen?
> Wie kann ich das wieder "gerade biegen"?
>
> 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] OSM Inspector - maxspeed

[Stefan Dettenhofer (StefanDausR)]

John07 schrieb:
> Danke, leider lädt das gerade sehr zäh, aber scheint am [EMAIL PROTECTED] 
> Server zu 
> liegen. Bitte an den Autor: Auch Mapnik als Layer auswählbar.
> Ansonsten, falls Geofabrik noch Platz und Rechenkapazität hat, könnten 
> sie das ja vllt. einbauen und damit einen aktuelleren Service anbieten. 
> Ich hoffe der ursprüngliche Autor ist dadurch dann nicht gekränkt.
>   

Hallo zusammen,
die maxspeed-Karte wird gerade wieder neu gerechnet. Zoom 0-12 sind 
schon online.
Ich habe dazu eine eigene Wiki-Seite angelegt:
http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte
Dort steht nun das Datum des Updates und eine Legende. Außerdem habe ich 
einige Werte ergänzt und Farben angepasst.

Wenn jemand geeigneten WEBSpace zur Verfügung hat, lade ich gerne die 
Tiles auch dorthin hoch!

Gruß,
Stefan


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

Re: [Talk-de] Luftbilder LVA Bayern

[Stefan Dettenhofer (StefanDausR)]

Hallo Martin,

zumindest für die Stadt Regensburg gibt es hier
http://www.statistik.regensburg.de/publikationen/amtliche_verzeichnisse.php
u.A. ein Straßenverzeichnis, das man zur Kontrolle verwenden kann.
Siehe auch hier:
http://wiki.openstreetmap.org/wiki/Regensburg

Martin Trautmann schrieb:
> Gäbe es aber vielleicht zumindest die Möglichkeit, ein entsprechendes 
> Straßenverzeichnis zu bekommen?
>
>
>   


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

Re: [Talk-de] OSM Inspector - maxspeed

[Stefan Dettenhofer (StefanDausR)]

John07 schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> John07 schrieb:
>>   
>> 
>>> Danke, leider lädt das gerade sehr zäh, aber scheint am [EMAIL PROTECTED] 
>>> Server zu 
>>> liegen. Bitte an den Autor: Auch Mapnik als Layer auswählbar.
>>> Ansonsten, falls Geofabrik noch Platz und Rechenkapazität hat, könnten 
>>> sie das ja vllt. einbauen und damit einen aktuelleren Service anbieten. 
>>> Ich hoffe der ursprüngliche Autor ist dadurch dann nicht gekränkt.
>>>   
>>> 
>>>   
>> Hallo zusammen,
>> die maxspeed-Karte wird gerade wieder neu gerechnet. Zoom 0-12 sind 
>> schon online.
>> Ich habe dazu eine eigene Wiki-Seite angelegt:
>> http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte
>> Dort steht nun das Datum des Updates und eine Legende. Außerdem habe ich 
>> einige Werte ergänzt und Farben angepasst.
>>   
>> 
> Danke, habe auf der Diskussionsseite mal meine Wünsche ergänzt.
>   
>> Wenn jemand geeigneten WEBSpace zur Verfügung hat, lade ich gerne die 
>> Tiles auch dorthin hoch!
>>   
>> 
> Wie viel wird denn gebraucht? Ich bin sicher, dass sich hier jemand findet.
> Gruß
> Jonas
>
>   
Zoom 0-12 sind (aktuell) 158 MB in 60.633 Files und 300 Verzeichnissen
Zoom 13 sind (aktuell) 263 MB in 179.196 Files und 274 Verzeichnissen
Zoom 14 sind (bisher) 789 MB in 596.448 Files und 456 Verzeichnissen

Der Speicherplatz ist nicht so das Problem, aber der Upload via FTP ist 
sehr zeitintensiv, da es sich um so viele Einzeldateien handelt. 
Vielleicht ist aber auch nur mein alter Rechner, den ich als WEB-Server 
benutze zu langsam.

Ich bin gerade dabei, vor dem Transfer erst einmal alle leeren Kacheln 
(kleine PNG-Files) zu löschen, mal sehen, ob das was bringt.

Falls Du eine Möglichkeit hast, können wir das gerne mal testen!

Gruß,
Stefan


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

Re: [Talk-de] Luftbilder LVA Bayern

[Stefan Dettenhofer (StefanDausR)]

Markus schrieb:
> Hallo Stefan,
>
>   
>> für die Stadt Regensburg gibt es ein Straßenverzeichnis
>> 
>
> kannst Du das bitte anfordern und dann eintragen:
> http://wiki.openstreetmap.org/wiki/Straßenverzeichnis#Bayern
>
>   
>> das man zur Kontrolle verwenden kann
>> 
>
> Ja, dazu hat Sven Anders ein super Tool gebaut.
>
> Gruss, Markus
>
>   
Ja, das momentan verfügbare SV ist ein mehrseitiges PDF-File, das man 
sich neben den Rechner legen darf. Eine Veröffentlichung ist nicht 
eingeschlossen.

Ich werde aber mal sehen, ob ich offiziell eines bekomme (bzw. 
veröffentlichen darf)

Gruß,
Stefan


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

Re: [Talk-de] osm daten beschneiden

[Stefan Dettenhofer (StefanDausR)]

Christian Mayr schrieb:
>> das geht mit osmosis und mit einem perl script
>>
>> http://wiki.openstreetmap.org/wiki/Osmosis
>>
>> 
> leider finde ich kein beispiel für ein extrahieren mit einer bounding box
> hat da jemand einen beispielaufruf zur hand?
>
> gruesse
>   
Wenn es Dir nur um die beschnittenen OSM-Daten geht:
Ich erzeuge regelmäßig 1°x1°-Kacheln, die ich dann in das MAP-Format für 
NaviPOWM umwandle. Ich könne auch die OSM-Rohdaten zum Download 
bereitstellen.
Hinweis: Ich erzeuge nicht genau 1°x1° sondern etwas mehr, so dass eine 
kleine Überlappung besteht, da mir sonst im Grenzbereich Daten fehlen. 
Man sieht das z.B. auch daran, dass man nicht einfach Deutschland und 
Österreich zusammenkopieren kann. Da kann es Probleme (fehlende Daten) 
geben.

Gruß,
Stefan



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

Re: [Talk-de] OSM Inspector - maxspeed

[Stefan Dettenhofer (StefanDausR)]

Fabian Schmidt schrieb:
>
> Am 26.11.08 schrieb Stefan Dettenhofer (StefanDausR):
>
>> Der Speicherplatz ist nicht so das Problem, aber der Upload via FTP ist
>> sehr zeitintensiv, da es sich um so viele Einzeldateien handelt.
>
> Hilft denn sowas?
>
> tar cpf - dir | ssh [EMAIL PROTECTED] tar xpf -
> bzw.
> tar cpf - dir | ssh [EMAIL PROTECTED] "( cd targetdir && tar xpf - )"
>
>
> Gruß, Fabian.
>
Danke!
Ich mache es momentan so ähnlich mit 7z-Files. Mein eigener Server läuft 
unter Windows.
Die vielen Einzeldateien machen mich fertig: Ich lasse gerade alle 
leeren PNG-Files aus der Zoomstufe 14 mit einem BATCH-Befehl löschen:

for /R .\14\ %%N IN (*.PNG) DO if %%~zN LSS 1300 del %%N

das läuft nun schon seit 7 Stunden...

Gruß,
Stefan


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

Re: [Talk-de] Format umwandeln: GPX - DFK

[Stefan Dettenhofer (StefanDausR)]

Markus schrieb:
> Hallo!
>
> in meinem Bereich gibt es ein ziemliches Durcheinander der sich 
> überlagernden Grenzen.
> Unsere Gemeindegrenze habe ich als GPX, und möchte sie gern von unserem 
> örtlichen Vermesser prüfen und mit den Infas-Daten vergleichen lassen.
> Dort kann man aber nur DFK importieren.
>
> Wer kann mir das umwandeln?
>
> Gruss, Markus
>
>   
Ich habe einen Konverter geschrieben, der DFK lesen kann und dann z.B. 
nach DXF wandelt.
In welchem System sind die DFK-Daten? Normalerweise sind die in 
GK-Koordinaten. Die müsste man auch noch nach WGS-84 konvertieren.

Gruß,
Stefan


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

Re: [Talk-de] Firefox 3 und WMS

[Stefan Dettenhofer (StefanDausR)]

Mit welchen Abweichungen ist denn zu rechnen, wenn die Luftbilder (in 
GK) vom WMS-Server nach WGS-84 umgerechnet werden und dann vielleicht in 
JOSM noch nach Mercator?
Wäre es da nicht sinnvoller, in JOSM eine GK-Projektion einzubauen? 
Diese ist lokal rechtwinkelig.

Gruß,
Stefan

Frederik Ramm schrieb:
> Hallo,
>
> Chris66 wrote:
>   
>> Genau deswegen hatte ich ja den Vorschlag gemacht eines Zwischendings
>> zwischen WGS84 und Mercator (lineare Skalierung in y-Richtung um Faktor
>> 1.6/einstellbar ).
>> 
>
> Kommt nicht in Frage. Wir erfinden bei OSM schon genug Räder neu. Eine 
> eigene Projektion braucht es nicht auch noch.
>
> Bye
> Frederik
>
>   



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

Re: [Talk-de] GK-Projektion

[Stefan Dettenhofer (StefanDausR)]

Hallo,

in der Oberpfalz gilt EPSG:31468
Ich habe die Umrechnung GK_3(Zone 4)<->WGS84 (also EPSG:31468 <-> 
EPSG:4326) mit den Sources von GEOTRANS gemacht. Man muss aber schon 
genau aufpassen, was man tut!

GK-Koordinaten benutzen das Ellipsoid "Bessel 1841" und als Datum 
"Deutsches Hauptdreiecksnetz"
WGS-84 (EPSG:4326) benutzt das Ellipsoid "WGS 84" und als Datum "World 
Geodetic System 1984"
Beim staatl. Vermessungsamt ist auch noch EPSG:4314 (DHDN) gebräuchlich, 
das benutzt das Ellipsoid "Bessel 1841" und als Datum "Deutsches 
Hauptdreiecksnetz"

EPSG:4326 und EPSG:4314 haben in Regensburg einen Offset von ca. 150m

Zur prinzipiellen Umrechnung GK -> WGS84
Du musst die transversalen Mercatorkoordinaten in geodätische umrechnen 
und dann einen "Molodensky Shift" ausführen, der den Ellipsoidübergang 
berechnet.

Gruß,
Stefan



Dominik Spies schrieb:
> Hallo,
>
> ich hätte mal eine Frage zur GK-Projektion (wegen der LVA-Bayern Luftbilder).
>
> Würde man so eine Projektion in einen Editor einbauen, könnte man
> heweils nur einen Streifen anzeigen / bearbeiten, richtig?
>
> Laut 
> http://www.gdi.bayern.de/home_data/Kopie%20von%20GDI-Web/Geowebdienste/geowebdienste.htm
> gibts die 2m DOPs in:
>
> EPSG:31464, 31468, 31494 über den WMS. Welche erhalten wir auf DVD?
> Wie sind überhaupt 31464 und 31494 definiert? Infos darüber habe ich
> nur insoweit gefunden, dass man sie nicht mehr benutzen sollte, da
> abgelehnt bzw. deprecated.
>
> 31468 wäre ganz normal GK4 (10.5°-13.5°) mit Bessel-Elipsoid.
>
> So, um jetzt ein WGS-84 Datum in ein x/y Wert auf den DOPs
> auszurechnen, müsste man erst in ein Bessel-Datum umrechnen und dann
> in GK4 projezieren, richtig?
> Für x/y -> WGS-84 Datum einfach umgekehrt.
>
> Ich bin auf der Suche nach Formeln (incl. einer für nicht Mathematiker
> / Geographen verständliche) Erklärung, um sie in Programmcode
> umzusetzen.
> Gefunden habe ich bisher:
> http://www-ipf.bau-verm.uni-karlsruhe.de/trafo/trafo.pdf
>
> Die GK-Formel kapier ich wohl, Probleme bereitet mir der Eilpsoidübergang.
>
> Ein Elipsoid ist ja durch a,b, und f (Halbachsen + Abplattung)
> definiert.. Wie genau dazu jetzt die Formeln aus dem PDF bei 1.7
> passen, bleibt mir noch verschlossen..
>
> Kann mir da jemand helfen?
>
> Gruß,
>
> Dominik
>
> ___
> 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] WGS-84 <-> GK; war: Firefox 3 und WMS

[Stefan Dettenhofer (StefanDausR)]

Hallo Frederik,

wie ich schon an anderer Stelle mal geschrieben habe, benutze ich für 
die Transformation GK <-> WGS-84 die sources von GEOTRANS
http://earth-info.nga.mil/GandG/geotrans/

Ich benutze diese unter Windows mit C/C++ und unter WinCE in C. 
Allerdings habe ich mit JAVA noch nichts gemacht.
Es gibt auch ein online-Umrechnungstool, das dies GEOTRANS-Sources nutzt 
und in JavaSkript implementiert ist:
http://www.orchids.de/florkart/skripte/GeoTrans.htm

Wenn also Bedarf besteht, dann kann ich Dir die nötigen C-Sourcen 
zusammenstellen.

Zur "Genauigkeit" der Umrechnung:
- Höhe wird nicht berücksichtigt!
- in Regensburg gelten ungefähr folgende Zusammenhänge:
+ im Rechtswert (GK) entsprechen 10 Meter 0,49'' (geogr.)
+ im Hochwert (GK) entsprechen 10 Meter 0,33'' (geogr.)
- Umrechnungsbeispiele mit verschiedenen Systemen:
Grundlage ist folgende GK-Koordinate: R=4507545.14 H=5431102.70
System E N
mein Programm: 12g 06' 06,11'' 49g 01' 01,92''
www.IPF.uni.karlsruhe.de: 12g 06' 06,65'' 49g 01' 01,53''
www.orchids.de: 12g 06' 06,10'' 49g 01' 01,93''
MapBender (Intranet Stadt R): 12g 06' 06,25'' 49g 01' 01,86''
(GPS-Gerät: 12g 06' 05,8'' 49g 01' 02,1'')

Fazit: Eine absolut genaue Umrechnung von GK nach WGS-84 ist m.E. nicht 
möglich! Es können sich -je nach verwendeter Formel- Abweichungen um 
einige Meter ergeben!

Ich hatte auch geogr. Koordinaten und die GK-Koordinaten des staatl. 
Vermessungsamtes verglichen. Dort wurde aber kein Ellipsoidübergang 
berechnet (also geogr. Koordinaten mit Bessel-Ellipsoid!), daher waren 
die Ergebnisse viel genauer.

Gruß,
Stefan



Frederik Ramm schrieb:
> Wenn mir irgendjemand eine simple Rechenvorschrift, in beliebiger 
> Programmiersprache oder auch "Pseudocode" liefern kann, die Schritt fuer 
> Schritt beschreibt, wie ich aus einer geographischen Laenge und Breite 
> nach WGS84 einen Rechts- und Hochwert nach GKx bekomme, dann baue ich 
> das sofort in JOSM ein. Aber bitte in dieser Anleitung keine 
> Formulierungen wie "und hier dann einfach den 
> von-Neumann-Brennickmeyer-Algorithmus anwenden" oder sowas ;-) nur 
> Grundrechenarten, Trigonometrie und von mir aus LA.
>
> Bye
> Frederik
>
>   


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

wenn man davon ausgeht, dass residential auch nur innerhalb 
geschlossener Ortschaften verwendet wird (so wie es sein sollte) und das 
überall 50 km/h impliziert, dann ist das ok.
Man könnte dann noch bei living_street irgend etwas zwischen 5 und 10 
km/h annehmen.
Wobei diese "Defaulttabellen" dann in allen Anwendungen und 
Karten-Zeichenvorschriften gleichermaßen angewendet werden müssten.

Das mit maxspeed wird aber besser!
In meiner neuesten maxspeed-Karte habe ich übrigens extra Wien mit 
aufgenommen!

Gruß,
Stefan

Wolfgang W. Wasserburger schrieb:
> wobei ich dies auf primary, secondary, tertiary und ggf. highway und Trunk 
> beschränken würde. Bei residential gibt das eigentlich keinen Sinn.
> Im Moment kommt maxspeed allerdings reichlich selten vor ;-)
>
> lg Wolfgang


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

wenn physisch 2 Schilder da sind, ist die Sache klar!
bei uns ist es aber manchmal so, dass ein Schild zweigeteilt 
(untereinander) ist:
- neue Ort
- der alte Ort durchgestrichen

Gruß,
Stefan

Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> wie machst Du das eigentlich bei Ortschaften, die direkt ineinander 
>> übergehen?
>> - Zwei Schilder knapp hintereinander
>> - Zwei Ortsnamen angeben
>> 
>
> Du hast zwar nicht mich angesprochen, aber ich antworte mal:
> Ich persönlich mappe beide Schilder, da sie ja physisch existent
> sind. So kann man irgendwann auch mal eine Schildermastanalyse
> durchführen (der ADAC macht sowas ja gerne).
>   


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

Ich bin eigentlich eher der Verfechter des expliziten taggen, d.h. 
einfach ein maxspeed an alle ways.
Mir ist klar, dass es viele Gegenargumente dazu gibt, aber momentan ist 
das die eindeutigste Lösung.

Gruß,
Stefan


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

wie machst Du das eigentlich bei Ortschaften, die direkt ineinander 
übergehen?
- Zwei Schilder knapp hintereinander
- Zwei Ortsnamen angeben

Ich habe bisher die zweite Variante gemacht, also "Ort1/Ort2", wobei der 
"Ort1" der ist, der (in Wegrichtung) neu anfängt und "Ort2" der, der 
aufhört.

Gruß,
Stefan

Alex Schulze schrieb:
> Ich jedenfalls tage immer die Ortseingangsschilder mit. Die jetzt ja auch 
> schön in JOSM dargestellt sind.
>   


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

Es kann schon sein, dass bei vollständiger "maxspeed-Betaggung" da etwas 
overhead erzeugt wird, aber es ist meines Erachtens trotzdem die einzige 
sinnvolle Möglichkeit.
Alternativ müsste ja z.B. zusätzlich zur (rechtlichen) Ortsgrenze noch 
die beschilderte Ortsgrenze an Polygon erfasst werden, um z.B. die Fälle 
zu erfassen, bei denen einen BAB durch ein (rechtliches) Ortsgebiet 
geht. Desweiteren müsste dann einen Vorverarbeitung der OSM-Dateien 
erfolgen, die dann auch nichts anderes macht, als die maxspeed-Tags nach 
gewissen Regeln zu ergänzen.
Dann kann man sie doch auch gleich direkt dran hängen.

Ich gebe Dir recht, dass maxspeed vom Fortbewegungsmittel abhängen kann. 
Diesen Fall gibt es aber sowohl bei explizit ausgeschilderten 
Tempolimits als auch bei impliziten maxspeeds.
Die maxspeed-tags müssen dazu erweitert werden, um das 
Fortbewegungsmittel definieren zu können (un die Richtungsabhängigkeit 
und die Geschwindigkeit pro Fahrspur, und ...)

Gruß,
Stefan

Mario Salvini schrieb:
> das erinnert mich gerade an eine nicht ewig zurückliegende Diskussion ;)
> Vollständige maxspeed-Betaggung ist nicht nur sinnloser Overhead, 
> sondern auch faktisch falsch, da nur explizit ausgeschilderte 
> Begrenzungen für alle gelten, implizierte Maxspeeds aber vom 
> Fortbewegungsmittel (vehicle_type) abhängig sind.
>
>   


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

Re: [Talk-de] MaxSpeed-Erfassung - war: LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Zur Erfassung (und Kontrolle) des maxspeed-Tags nutze ich NaviPOWM. Ich 
habe mir noch Buttons (mit koord465) erstellt, mit denen ich die Tags 
als Waypoints erfassen kann (s. hier):
http://forum.pocketnavigation.de/thread.php?postid=2115770#post2115770
Diese kann ich in GPX wandeln und in JOSM einladen. Parallel kann ich 
auch noch loggen.

Die Reaktion war aber ziemlich gering, so dass ich davon ausgehe, dass 
daran kein Bedarf besteht.

Mit dem System habe ich zumindest in meiner Gegend die maxspeed-Tags 
erfasst.
Die Karten für NaviPOWM stelle ich ja auch -genauso wie die 
maxspeed-Karte- bereit.

Gruß,
Stefan


John07 schrieb:
> Florian Lohoff schrieb:
>   
>> On Tue, Dec 02, 2008 at 04:19:00PM +, Johann H. Addicks wrote:
>>   
>> 
>>> Will sagen: Unsere Straßen mögen zwar im Renderer oft  
>>> schöner (runder) aussehen, aber die Datenbasis für's Routing  
>>> ist bei Teleatlas und Co noch meilenweit vor uns.
>>> 
>>>   
>> Es ist ja noch viel wilder - Das problem laesst sich ja schon schoen an
>> maxspeeds sehen das dort nur wenig interesse ist das flaechendeckend zu
>> taggen. Das waere ja typischerweise sogar schon fuer otto-normal-mapper
>> interessant. Problem ist derzeit vermutlich hauptsaechlich das es keine
>> schoene visualisierung gibt.
>> 
> http://wince.dentro.info/koord/osm/KosmosMap.htm kennst du, oder? Gut, 
> kann man noch verbessern. Also hilf mit! 
> http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte
>   
>>  
>>
>> Bei den beschraenkungen die nur LKW interessieren wirds dann noch eine
>> stufe heftiger - Wen interessiert schon ob die Brücke 3,60m oder 4,0m
>> hoch ist - Das Auto passt immer durch. Und auch beschraenkungen der
>> tonnage interessiert keinen Autofahrer solange man jetzt keinen Maybach
>> sein eigen nennt (und Maybach Fahrer interessieren sich wohlmoeglich
>> nicht fuer OSM).
>>
>> D.h. bei den maxspeeds gaebe es noch interesse - ist bloss schlecht
>> gepflegt - und bei hoehe, breite oder gewicht interessiert es den
>> normal-mapper nicht und es wird auch nicht visualisiert.
>>
>> Ich haette ja gerne noch einen view im OSM Inspektor fuer maxspeed und
>> jegliche andere restrictions d.h. gewicht, breite, hoehe - Da die nicht
>> so oft vorkommen koennte man die gemeinsam visualisieren.
>>   
>> 
> Würde ich mir auch wünschen.
> Ich würde aber nicht ganz so schwarz malen. Wenn es wirklich mal ein 
> Navi gibt, dass mit OSM-Material LKW-Routen berechnet, dann hat das 
> bestimmt auch OSB an Bord. Und damit würden sicher auch LKW-Fahrer 
> Brückenhöhen etc. eintragen.
> Hab schon von einigen Leuten gehört, die auch Fehler an Teleatlas melden 
> und sich dann ärgern, dass sie nicht ausgebessert werden. Bei OSM wäre 
> das viel leichter und würde sicher ausgebessert werden.
> Wenn es eine einfache Lösung, wie OSB, auf normalen Geräten ohne Hack 
> gibt, sehe ich sehr viel Potenzial für eine gute Datenpflege.
> Gruß
> Jonas
>
>
>   



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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

ok, vielleicht findet sich ja mal ein guter Mittelweg.
Zumindest bis alle geschlossenen Ortschaften eine Relation und ein 
Grenzpolygon haben, werde ich lieber ein paar mehr (evtl später 
überflüssige) maxspeed-tags anbringen:
Wenn durch eine kleine geschlossene Ortschaft eine Durchgangsstraße 
(secondary, tertiary, ...) verläuft, dann setzte ich das maxspeed-tag 
innerhalb der Ortsschilder auf 50.
Ich erlaube mir auch mal ein maxspeed=100 zu taggen, das nicht 
beschildert ist (default), damit klar ist, dass hier schon maxspeed 
erfasst ist. Man könnte natürlich auch ein maxspeed=default oder sonst 
was nehmen.

Gruß,
Stefan

Mario Salvini schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Es kann schon sein, dass bei vollständiger "maxspeed-Betaggung" da etwas 
>> overhead erzeugt wird, aber es ist meines Erachtens trotzdem die einzige 
>> sinnvolle Möglichkeit.
>>   
>> 
> vollständige "maxspeed-Betaggung" würde heißen
> Jeder highway bekäme ein maxspeed=* maxspeed:hgv=* maxspeed:goods=* 
> das is soviel Overhead dass es schon an Tagging-Wahnsinn grenzt ;)
>
>   
>> Alternativ müsste ja z.B. zusätzlich zur (rechtlichen) Ortsgrenze noch 
>> die beschilderte Ortsgrenze an Polygon erfasst werden, um z.B. die Fälle 
>> zu erfassen, bei denen einen BAB durch ein (rechtliches) Ortsgebiet 
>> geht. 
>> 
> beschilderte Ortsgrenzen sind in den wenigstens Fällen lückenlos. Hier 
> in meiner Gegend gibt es keine einzige Stadt wo an jedem "die Stadt 
> betreten/verlassenden" Weg/STraße ein Ortsausgangsschild wäre. Eine 
> Möglichkeit wäre: Alle Wegstücke markieren und mit in in die 
> place-Relation (samt umschließendes Polygon und Stadtzentrum-Node) 
> packen. Das Problem mit der Autobahn lässt sich aber noch viel einfach 
> lösen, in dem man explizit in den Defaults festlegt, dass auf der 
> Autobahn immer maxspeed=no gilt. (So wie es übrigens auch in den 
> Default-Tabellen schon erfasst ist.)
>   
>> Desweiteren müsste dann einen Vorverarbeitung der OSM-Dateien 
>> erfolgen, die dann auch nichts anderes macht, als die maxspeed-Tags nach 
>> gewissen Regeln zu ergänzen.
>> Dann kann man sie doch auch gleich direkt dran hängen.
>>   
>> 
> Wie wir schon festgestellt haben, gebraucht jedes Verkehrsmittel eigene 
> Defaults. Dementsprechend ist auch die Vorarbeitung für jeden 
> vehicle_type anders. Außerdem minimiert der Zwischenschritt das 
> Fehlerpotenzial (menschen machen nunmal Fehler) bzw. minimiren den 
> Aufwand der Pflege an den Stellen wo noch Fehler sind.
>   
>> Ich gebe Dir recht, dass maxspeed vom Fortbewegungsmittel abhängen kann. 
>> Diesen Fall gibt es aber sowohl bei explizit ausgeschilderten 
>> Tempolimits als auch bei impliziten maxspeeds.
>>   
>> 
> wenn da einfach nut ein rundes Schild (weißer Grund, roter rand) mit 
> Zahl steht, dann gilt dass für alle Verkehrsteilnehmer. Klar kann man 
> alles durch Zusatzschilder auf bestimmt Gruppen beschränken, aber der 
> Großteil sind explizite Beschränkungen für alle.
>   
>> Die maxspeed-tags müssen dazu erweitert werden, um das 
>> Fortbewegungsmittel definieren zu können (un die Richtungsabhängigkeit 
>> und die Geschwindigkeit pro Fahrspur, und ...)
>>   
>> 
> und bis dahin macht eine "vollständige maxspeed-Betaggung" erst recht 
> keinen Sinn, sondern erzeugt wie schon erwähnt nur falsche Daten.
>   
>> Gruß,
>> Stefan
>>
>> Mario Salvini schrieb:
>>   
>> 
>>> das erinnert mich gerade an eine nicht ewig zurückliegende Diskussion ;)
>>> Vollständige maxspeed-Betaggung ist nicht nur sinnloser Overhead, 
>>> sondern auch faktisch falsch, da nur explizit ausgeschilderte 
>>> Begrenzungen für alle gelten, implizierte Maxspeeds aber vom 
>>> Fortbewegungsmittel (vehicle_type) abhängig sind.
>>> 
>>>   
>
>
> ___
> 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] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

Warum sollte ich die extra kennzeichnen? Wenn sie überflüssig sind, dann 
bedeutet es doch, dass sie mit dem Defaultwert übereinstimmen und können 
dann maschinell bereinigt werden!
Wenn das nicht möglich ist, dann taugt der Defaultwert auch nichts.

Gruß,
Stefan

Marc Schütz schrieb:
>> Dann markier bitte diese impliziten maxspeeds irgendwie, am besten 
>> maschinell auswertbar, so dass erkennbar ist, welche davon überflüssig sind.
>>
>> Wie wärs mit implicit_maxspeed=yes, oder gleich implicit_maxspeed=100 statt 
>> maxspeed=100?
>>
>> 


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

Re: [Talk-de] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Das meinst Du aber jetzt nicht ernst, so etwas hier vorzuschlagen, oder? 
Das PSF-Format ist nicht ganz triveal.

Für POIs (GoPal 2.x bis 4.1) gibt es ja schon einen Konverter und 
entsprechende PSF-POIs.

Gruß,
Stefan

André Reichelt schrieb:
> Sofern es nicht schon Konverter gibt, könnten villeicht mal ein paar
> Hacker versuchen, das Format zu entschlüsseln und den passenden
> Konverter zu entwickeln.
>
>   


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

was aber wiederum klar macht, dass solche Polygone nicht unbedingt als 
maxspeed-Default dienen können!

Stefan

Frederik Ramm schrieb:
> Hallo,
>
> Sascha Silbe wrote:
>   
>> Geschlossene Ortschaft nach StVO (die gelben 
>> Ortstafeln) und die Ausdehnung eines Ortes (-> Adressen) sind nicht 
>> identisch.
>> 
>
> Genau, und "built-up area" ist einfach "bebautes Gebiet" - also was man 
> typischerweise von einem Luftbild sofort einzeichnen kann. Der Begriff 
> hat im Englischen nicht den scharf begrenzten Charakter von unserem 
> "geschlossene Ortschaft". Es ist also damit zu rechnen, dass jemand, der 
> nicht aus Deutschland ist, eine Grenze, die mit "built-up area" getaggt 
> ist, so veraendern wuerde, dass sie eben dem bebauten Gebiet entspricht.
>
> Bye
> Frederik
>
>   



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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

Ja genau! Denn ein "Ortsschild-Polygon" ist nicht praktikabel. Es 
besteht dann auch immer die Verwechslungsgefahr mit der Ortsgernze.
Eine Relation wäre für kleine Orte Ok, aber alle Starßen von Berlin in 
eine Relation zu packen, dürfte auch nicht benutzerfreundlich sein. Dann 
müssten pro Stadtbezirk Relationen aufgebaut werden, die dann wieder in 
einer Superrelation zusammengefasst werden...

Also ein tag an alle ways innerhalb der "Ortsschildgrenze" ist für alle 
Anwendungen sinnvoll (auch für maxspeed!).

Es ist ja auch zu beachten, dass jeder Weg am Ortsschild aufgeteilt 
werden muss!

Gruß,
Stefan

Torsten Leistikow schrieb:
> Noch viel einfacher ist es, den Weg nicht in eine Relation zu packen,
> sondern die Information einfach an jeden betroffenen Weg per Tag
> anzuhaengen.
> Das ist auch leichter zu kontrollieren und es kann auch nicht so leicht
> kaputt gehen.
>
> Gruss
> Torsten
>   



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

Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben

[Stefan Dettenhofer (StefanDausR)]

Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier
http://stadtplan.regensburg.de/stadtplan.html
ansehen!
Stadtplan abwählen -> Luftbilder (Orthofotos) -> Bayern (2m 
Bodenauflösung) anwählen
Aber Achtung, es gibt für Regensburg auch welche in sehr viel besserer 
Auflösung!

Gruß,
Stefan

Tobias Wendorff schrieb:
> Ich bete nur, dass die Bilder nicht im Sommer aufgenommen wurden,
> da man sonst die Straßen und Wege vor lauter Vegetation nicht sieht.
>
> ___
> 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] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Warum muss da gleich einen eigene Hardware mit? Eine gute Software würde 
doch schon reichen, oder?

NaviPOWM ist ja schon einmal ein guter Ansatz!

Gruß,
Stefan

Tobias Wendorff schrieb:
> Markus schrieb:
>   
>>> Jedoch braucht man dazu erstmal Kunden.
>>>   
>> Gerät incl OSM-Karte 200 €:
>> +1 Markus
>> 
>
> Ich würde eine Null hinten dran setzen. Für 200 EUR bekommst Du
> bei einer 1.000er Serie gerade mal ein geeignetes Touchscreen-DPL.
>   


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

Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben

[Stefan Dettenhofer (StefanDausR)]

Ja die haben für die 0,2m-Auflösung den Maßstab begrenzt, da es noch 
Luftbilder in besserer Qualität gibt!

Stefan

Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier
>> http://stadtplan.regensburg.de/stadtplan.html
>> ansehen!
>> Stadtplan abwählen -> Luftbilder (Orthofotos) -> Bayern (2m 
>> Bodenauflösung) anwählen
>> 
>
> Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann
> ich noch nicht mal die Vegetation erkennen :-)
>
> ___
> 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] Luftbilder LVA Bayern - Vertrag unterschrieben

[Stefan Dettenhofer (StefanDausR)]

Nachtrag:
hier
http://stadtplan.regensburg.de/stadtportal.html
kann man auch die Stadtgrundkarte mit allen Gebäuden dazu einblenden!

Stefan

Stefan Dettenhofer (StefanDausR) schrieb:
> Ja die haben für die 0,2m-Auflösung den Maßstab begrenzt, da es noch 
> Luftbilder in besserer Qualität gibt!
>
> Stefan
>
> Tobias Wendorff schrieb:
>   
>> Stefan Dettenhofer (StefanDausR) schrieb:
>>   
>> 
>>> Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier
>>> http://stadtplan.regensburg.de/stadtplan.html
>>> ansehen!
>>> Stadtplan abwählen -> Luftbilder (Orthofotos) -> Bayern (2m 
>>> Bodenauflösung) anwählen
>>>
>>>   



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

Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben

[Stefan Dettenhofer (StefanDausR)]

Die Qualität der 2m-Daten entspricht der hier
http://www.geodaten.bayern.de/BayernViewer/index.cgi
->Orthofotos
(Es sind die selben Bilder, die ich auch für Regensburg habe)

Stefan
> Hi Tobias,
>
>   
>> Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann
>> ich noch nicht mal die Vegetation erkennen :-)
>> 
>
> Dann sollten wir auf jeden Fall sicherstellen,
> dass bei uns die Anleitung zur Nutzung der DOPs
> in JOSM und Potlatch eindeutig und nachvollziebar sind!
>
> Gruss, Markus
>
> --
> http://wiki.openstreetmap.org/wiki/de:Luftbilder_aus_Bayern
>
> ___
> 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] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Bei den Medion PNAs (Hersteller ist m.W. Mitac) ist das definitiv kein 
Problem!

Du brauchst da nichts an der Firmware zu ändern. Er reicht die andere 
Software aufzuspielen und zu starten.
Selbst die mitgelieferte Navi-Software ist so offen Programmiert, dass 
man da selbst Änderungen machen kann und darf!

Man kann die Originalsoftware jederzeit wieder von DVD einspielen.

Und Garantie/Gewährleistung ist innerhalb der ersten 2 Jahre überhaupt 
kein Problem!

Gruß,
Stefan

Tobias Wendorff schrieb:
> André Reichelt schrieb:
>   
>> Tobias Wendorff schrieb:
>> 
>>> Für einen Gewerbetreibenden leider uninteressant, da mit solchen
>>> Eingriffen die Gewährleistung und Garantie verloren geht.
>>>   
>> Blödsinn! Ich habe ja an der Original-Software nichts geändert. Ich habe
>> das Programm nur auf die Speicherkarte gepackt und starte es dann ganz
>> normal über den Explorer. In den kommt man, wenn man beim "hochfahren"
>> des Navis eine bestimmte Taste gedrückt hält.
>> 
>
> Blödsinn, aha.
>
> Die "Garantie" ist sowieso freiwillig. Wenn der Hersteller Spuren
> einer anderen Software auf dem Telefon sieht, kann er sofort von
> seiner Garantie zurücktreten, auch wenn er sie beim Kauf zugesichert
> hat .
>
> Die "Gewährleistung" ist aber verpflichtend, aber nach den ersten
> sechs Monaten muss der *Käufer* nachweisen, dass die Mängel am Gerät
> nicht durch die eingespielte Software entstanden sind. Solche Beweise
> werden von Seiten der Gerichte und Hersteller natürlich nur von
> Gutachtern anerkannt.
>
> Der PDA mit Auslieferung als Navigationssystem (und somit eine
> Beschränkung der Möglichkeiten) ist vergleichbar mit Brandings von
> Handys vieler Mobilfunkbetreiber. Durch Software-Eingriff wird die
> Funktion / das mögliche Potential beschränkt und/oder verändert.
>
> Ich würde abwägen:
> Wenn man wirklich nur eine Taste drücken muss, um das fremde Programm
> zu starten und keine Manipulation an der Firmware oder mitgelieferten
> Software durchführen muss, dann ist es sicherlich akzeptabel. Man
> kann das Gerät beim Einschicken ggf. einfach zurücksetzen.
>
> Sobald man jedoch Core-Programme umschreibt, austauscht oder gar
> die Firmware austauscht, fällt das Ganze unter Urheberrechtsverstoß,
> da Software geschützt ist. Heise hat vor einiger Zeit genau dazu
> einen Artikel geschrieben (irgendwo bei Heise-Mobile).
>
> Viel gravierender sehe ich allerdings die markenrechtliche Probleme;
> lies hierzu § 24 Abs. 2 MarkenG - bezüglich ähnlicher Eingriffe,
> nämlich dem Entfernen von SIM-Locks hat der BGH bereits geurteilt:
> Entfernung ohne Eingriff in die Software => Markenverletzung
>
> ___
> 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] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Ich will nichts kompliziert machen, aber

1) gerade um der Lizenz gerecht zu werden, müssen die Daten frei 
verfügbar sein (oder zumindest müssen sie weitergegeben werden dürfen).
2) ein Vorteil von OSM ist ja gerade eine hohe Aktualität und da wäre es 
doch besser, die "verfeinerten" (kompilierten) OSM-Daten zum Download 
bereit zu stellen, als erst noch die Daten konvertieren zu müssen!

Weißt Du wie bei Medion ein Kartenupdate funktioniert? Genau so, wie Du 
es beschrieben hast. Danach muss noch ein Lizenzschlüssel eingegeben werden.

Du schreibst ja selbst von dem Problem, die Daten mit dem Gerät zu 
verkaufen!

Gruß,
Stefan

Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Die OSM-Daten könnten dabei frei downloadbar sein.
>> 
>
> Ja, mach es dem Nutzer noch komplizierter. Navi unter'm Weinachtsbaum
> auspacken, ans Internet anschließen, große Datenmenge runterladen etc.
>
> Das ist was für Übernormalbenutzer, aber nicht für die Oma, die das
> Navi zur Orientierung braucht.
>
>   
>> Wo ist da ein Lizenzproblem?
>> 
>
> Wenn Du die OSM-Daten mitlieferst, sind sie ein Teil des verkauften
> Gerätes. Wenn Du sie natürlich nur zum Download anbietest, ist das
> was Anderes.
>
> ___
> 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] Luftbilder LVA Bayern - Vertrag unterschrieben //?Vorgehensweise?

[Stefan Dettenhofer (StefanDausR)]

So wie es hier
http://wiki.openstreetmap.org/index.php/Regensburg
schon lange steht:

Als Referenz für die Vollständigkeit der Daten (Straßen und Bezirke) 
können können Informationen des Statistikamts Regensburg verwendet 
werden. Kostenlose Verzeichnisse als PDF gibt es hier 
<http://www.statistik.regensburg.de/publikationen/amtliche_verzeichnisse.php>. 
Weitere geologische und geografische etc. Informationen können unter 
Regensburg Informationen und Zahlen 
<http://www.statistik.regensburg.de/menue/informationen_u_zahlen.html> 
entnommen werden. Alle diese Informationen dürfen für Openstreetmap frei 
verwendet werden.

Die aktuellste und detaillierteste Karte gibt es von der Stadt 
<http://stadtplan.regensburg.de/>. Die Nutzungsbedingungen der Karte 
besagen, dass diese Karte nicht für OSM kopiert werden darf. Jedoch 
steht die Stadt Regensburg OSM "sehr aufgeschlossen" gegenüber. So lange 
die "Vektordaten von OSM erhoben werden" und nicht kopiert werden "kann 
die Karte als Grundlage kostenfrei genutzt werden".


Die selbe Aussage habe ich auch mündlich vom Vermessungsamt der Stadt 
Regensburg erhalten und sie von der Freigabe der Luftbilder unterrichtet.

Stefan


Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Die Daten von Regensburg dürfen zu diesem Zwecke (Überprüfung) von hier
>> http://stadtplan.regensburg.de/stadtportal.html
>> benutzt werden. Es darf aber keine Grafik abgezeichnet werden.
>> 
>
> Zur *Überprüfung* bedeutet, dass vorher schon mal jemand die Straße
> benannt haben muss. Wenn wir in der Oberpfalz aber Geisterstraßen
> eintragen, dann müssen wir auch die Genehmigung haben, z.B. den
> Straßennamen aus der "analogen Kartendatenbank" zu entnehmen.
>
> ___
> 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] Luftbilder LVA Bayern - Vertrag unterschrieben //?Vorgehensweise?

[Stefan Dettenhofer (StefanDausR)]

Die Daten von Regensburg dürfen zu diesem Zwecke (Überprüfung) von hier
http://stadtplan.regensburg.de/stadtportal.html
benutzt werden. Es darf aber keine Grafik abgezeichnet werden.

Stefan

Tobias Wendorff schrieb:
> Sven Geggus schrieb:
>   
>> Straßennamen können selbst durch Ortskundige ohne Spezialtechnik
>> ergänzt werden.
>> 
>
> Oder mit einer freundlichen Freigabe von Stadtplänen etc.
>
> ___
> 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] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Wieso? Man könnte doch die kommerziellen Daten strikt von den OSM-Daten trennen 
(2 unterschiedliche Dateien), die dann erst im Naviprogramm zusammengeführt 
werden.
Die OSM-Daten könnten dabei frei downloadbar sein.

Wo ist da ein Lizenzproblem?

Stefan


>AFAIK ist eine solche Vermischung durch die aktuelle Lizenzpolitik
>von OSM nicht möglich.


Stefan Dettenhofer (StefanDausR) schrieb:
> OSM-Daten könnten meines Erachtens im jetzigen Stadium höchstens eine 
> verkaufsfördernde Zugabe sein, deren Wirkung aber zukünftig sicher 
> nicht unterschätzt werden darf.
> Ich meine, wenn man spezielle Zusatzkarten (Karten aus Ländern, die 
> bei kommerziellen Anbietern nur schlecht erfasst sind oder sehr teuer 
> sind z.B. Wanderkarten) aus OSM gewinnt und diese als Ergänzung zu 
> kommerziellen Karten genutzt werden können, dann wäre das schon eine 
> tolle Sache.
>
> Gruß,
> Stefan
>
> Tobias Wendorff schrieb:
>> Allerdings ist OSM natürlich noch lange nicht reif, diesen Markt
>> zu decken.
>>   
>



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

Re: [Talk-de] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

OSM-Daten könnten meines Erachtens im jetzigen Stadium höchstens eine 
verkaufsfördernde Zugabe sein, deren Wirkung aber zukünftig sicher nicht 
unterschätzt werden darf.
Ich meine, wenn man spezielle Zusatzkarten (Karten aus Ländern, die bei 
kommerziellen Anbietern nur schlecht erfasst sind oder sehr teuer sind 
z.B. Wanderkarten) aus OSM gewinnt und diese als Ergänzung zu 
kommerziellen Karten genutzt werden können, dann wäre das schon eine 
tolle Sache.

Gruß,
Stefan

Tobias Wendorff schrieb:
> Allerdings ist OSM natürlich noch lange nicht reif, diesen Markt
> zu decken.
>   


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

Re: [Talk-de] Nachteil barometrischer Höhenmessung

[Stefan Dettenhofer (StefanDausR)]

Wenn es jemandem hilft:
Ich habe ein Programm für WinCE geschrieben, mit dem man die Höhe und 
Position (und Geschwindigkeit, etc.) loggen und nach GPX konvertrieren 
kann. Das läuft auf meinem Medion wunderbar.

Stefan

Holger Issle schrieb:
>> Du nimmst in Deinem Beispiel an, dass es schon einen Logger gibt, der zu 
>> den Trackpunkten automatisch Höhen aufzeichnet?
>> 
> Welche tun das nicht? ...wunder...
>   


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

Re: [Talk-de] Gauß-Krüger > WGS-84

[Stefan Dettenhofer (StefanDausR)]

Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte 
GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert 
werden weggelassen!
Das hat auch einen ganz praktischen (historischen) Grund:
Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, 
welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. 
Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst 
frühere Versionen von AutoCad konnte nicht vernünftig mit den 
ungekürzten Koordinaten arbeiten.

Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den 
Rechtswert die Nummer des Meridianstreifens, auf den sich die 
Koordinaten beziehen!

Hier ist noch eine Online-Umrechnung
http://www.orchids.de/florkart/skripte/GeoTrans.htm


Gruß,
Stefan


Marco Lechner schrieb:
> Hallo Markus,
>
> die von Dir angegebenen Koordinaten sind so keine
> Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind.
>
> Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte,
> da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die
> erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung
> notwendig.
>
>   


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

Re: [Talk-de] Gauß-Krüger > WGS-84

[Stefan Dettenhofer (StefanDausR)]

Mit Geotrans (link s. unten) und den GK-Koordinaten (auf ganze Meter 
gerundet) erhalte ich:
GK: R=4452306 H=5495775
WGS-84: 11.3387955°E 49.5968617°N

Gruß,
Stefan

Marco Lechner schrieb:
> das ist mir schon klar - nur leider hat Markus nicht angegeben wo er
> sich denn ungefähr befindet =>
>
> im Bereich 6° Ost:
> GK: 2452305.9 5495774.9
> latlon/WGS84: 5d20'22.957"E   49d35'48.46"N
>
> im Bereich 9° Ost:
> GK: 3452305.9 5495774.9
> latlon/WGS84: 8d20'21.382"E   49d35'48.524"N
>
> im Bereich 12° Ost:
> GK: 4452305.9 5495774.9
> latlon/WGS84: 11d20'19.815"E  49d35'48.628"N
>
> jeweils mit proj gerechnet (wie im Wiki angegeben):
> $ cs2cs -E +init=epsg:31466 +to +init=epsg:4326 <   
>> 2452305.9 5495774.9
>> EOF
>> 
>
> für Meridianstreifen 3 bzw. 4 eben mit epsg:31467 bzw. epsg:31468 und
> einem Rechtswert (Input) von 3452305.9 bzw. 4452305.9
>
> Marco
>
> P.S. Hoffentlich waren in den Ursprungskoordintaen Rechts- und Hochwert
> nicht vertauscht ;-)
>
>
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte 
>> GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert 
>> werden weggelassen!
>> Das hat auch einen ganz praktischen (historischen) Grund:
>> Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, 
>> welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. 
>> Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst 
>> frühere Versionen von AutoCad konnte nicht vernünftig mit den 
>> ungekürzten Koordinaten arbeiten.
>>
>> Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den 
>> Rechtswert die Nummer des Meridianstreifens, auf den sich die 
>> Koordinaten beziehen!
>>
>> Hier ist noch eine Online-Umrechnung
>> http://www.orchids.de/florkart/skripte/GeoTrans.htm
>>
>>
>> Gruß,
>> Stefan
>>
>>
>> Marco Lechner schrieb:
>> 
>>> Hallo Markus,
>>>
>>> die von Dir angegebenen Koordinaten sind so keine
>>> Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind.
>>>
>>> Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte,
>>> da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die
>>> erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung
>>> notwendig.
>>>
>>>   
>>>   
>>



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

Re: [Talk-de] Kauß-Krüger > WGS-84

[Stefan Dettenhofer (StefanDausR)]

Ich hab es zwar nicht getestet, aber hier:
https://upd.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=deu&gdz_akt_zeile=3&gdz_anz_zeile=6&gdz_user_id=0
kannst Du auch Koordinaten-Dateien wandeln lassen.

Stefan

Tobias Wendorff schrieb:
> Oder Du findest jemanden, der cs2cs (etc.) auf seinem Linuxserver
> für alle laufen lässt.
>   


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

[Talk-de] 3D-NMEA-Aufzeichnung -> war: Nachte il barometrischer Höhenmessung

[Stefan Dettenhofer (StefanDausR)]

Hallo Markus,

meine Tools habe ich hier
http://wiki.openstreetmap.org/wiki/User:StefanDausR
aufgeführt. Ich werde aber (bei Gelegenheit) noch eine genauere 
Beschreibung zu meinem Programm koord465 erstellen, die sich nur auf das 
loggen bezieht.

Mein Programm ist über viele Parameter steuerbar, da ich es eigentlich 
zuerst speziell für GoPal entwickelt hatte um dort Koordinateneingaben 
zu ermöglichen. Es wurde immer erweitert und kann in Skins eingebaut werden.

Die Tracking-Funktion ist mehr ein "Abfall-Produkt".

Gruß,
Stefan

Markus schrieb:
> Hallo Stefan,
>
>   
>> Ich habe ein Programm für WinCE geschrieben, 
>> mit dem man die Höhe und  Position (und Geschwindigkeit, etc.) loggen 
>> und nach GPX konvertrieren kann. Das läuft auf meinem Medion wunderbar.
>> 
>
> Super!
>
> Damit können alle (Medion-) Navibesitzer bei OSM mitmachen.
>
> Kannst Du das Programm zum Download anbieten?
> Und im Wiki eine Beschreibung machen (deutsch und englisch)?
>
> Ich möchte die Beschreibung dann gern verlinken in
> http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo/neu
>
> 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] 3D-NMEA-Aufzeichnung -> war: Nachte il barometrischer Höhenmessung

[Stefan Dettenhofer (StefanDausR)]

Das ist schon richtig!
Aber das Tracking mit koord geht auch ohne GoPal und man kann Höhe und 
Geschwindigkeit gleichzeitig aufzeichnen. Außerdem kann man bei der 
Konvertierung nach GPX noch eine Mindestanzahl von Sats bzw. einen max. 
HDOP angeben und das ganze läuft direkt auf dem PNA.
Bei den GoPal GPX bekommst du auch pro Routenberechnung einen neue Datei.
Aber "viele Wege führen nach Rom".

Gruß,
Stefan

Johann H. Addicks schrieb:
>> Beschreibung zu meinem Programm koord465 erstellen, die sich nur auf das
>> loggen bezieht.
>> 
>
>   
>> Die Tracking-Funktion ist mehr ein "Abfall-Produkt".
>> 
>
> Naja, leider ist das Programm inzwischen für's Tracklogging   
> überflüssig geworden bei den Medion-Navis.
>
> Nein, nicht weil GPS-Babel das TRK-Format selbst wandeln  
> kann, sondern weil GoPAL jetzt selbst GPX-Dateien speichert.
> Nur leider jetzt ohne Angaben zu Fix/HDOP/VDOP...
> Oder kennt jemand einen Trick, wie man das zurückdreht?
>
> -jha-
>   


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

Re: [Talk-de] 3D-NMEA-Aufzeichnung -> war: Nachte il barometrischer Höhenmessung

[Stefan Dettenhofer (StefanDausR)]

Das geht genauso, wie es seit GoPal 2.x funktioniert hat:
Das Verzeichnis
\Storage Card\Tracks
anlegen und schon werden dort -unabhängig von irgendwelchen anderen 
Einstellungen- *.trk-Dateien erzeugt, sobald GoPal läuft.
Die TRK-Dateien sind aber wieder ohne Höhe! Also Du kannst dann entweder 
GPX und TRK parallel aufzeichnen und nachher zusammenführen, oder Du 
nutzt doch Koord und hast eine komplette Datei...

Stefan


Johann H. Addicks schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>
>   
>>> Oder kennt jemand einen Trick, wie man das zurückdreht?
>>>   
>> Bei den GoPal GPX bekommst du auch pro Routenberechnung einen neue Datei.
>> Aber "viele Wege führen nach Rom".
>> 
>
> Ja leider.. Deshalb fragte ich ja: Wie kann ich bei GoPal4.5 wieder
> TRK-Dateien aufzeichnen lassen? Wo ist besagter Weg nach Rom?
>
> -jha-


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

Re: [Talk-de] Gauß-Krüger > WGS-84

[Stefan Dettenhofer (StefanDausR)]

Ich denke, das Problem ist weniger die Rechenungenauigkeit, als die 
Verwendung verschiedener Algorithmen und unterschiedlicher Parametersätze.
Einen "schlechten" Code erkennt man schon mal daran, dass die 
Rück-Umrechnung (GK->WGS84->GK) ungenaue Ergebnisse liefert. Hierbei 
solle es aber nur Abweichungen im cm-Bereich geben.
Die verschiedenen Umrechnungsmethoden liefern aber m.W. lokal betrachtet 
einen absoluten Fehler im bereich von 1-3m. Der differentielle Fehler 
dürfte geringer sein

Die Vermesser nutzen ja immer Referenzpunkte, auf die sie ihre Messung 
beziehen können. Die gemessenen Werte werden dann später erst in das 
vorhandene Punktraster eingerechnet und "ausgeglichen".

Miriam Tolke schrieb:
> Wolfgang W. Wasserburger <[EMAIL PROTECTED]> schrieb am Mi, 10.12.2008:
>
>   
>> Die Umrechnung beinhaltet jede Menge Funktionen
>> (Winkelfunktionen und Wurzeln), die in Computern nicht exakt abgebildet
>> werden und in verschiedenen Programmiersprachen unterschiedlich genau
>> sind. Außerdem sind Iterationen drinnen. Je nach Abbruchbedingung gibt
>> es so auch noch Abweichungen.
>> 
>
> Also ist nicht nur die Programmierung, sondern auch die Kodierung ein 
> möglicher Grund für Fehler. Es ist sicher ein Unterschied die Konvertierung 
> mal kurz in PHP oder Perl hinzurotzen oder guten Mathe-Libs sorgfältig in 
> Java, C oder Fortran zu verwenden. Trotzdem, sollten nicht zumindest die vom 
> Geodatenzentrum und vom USGS viel Sorgfalt verwendet haben und zumindest auf 
> sechs Stellen deckungsgleich sein?
>
> Heutzutage wird doch auch mit GPS vermessen und durch Postprocessing 
> Genauigkeiten im Millimeterbereich generiert. Und dann kommt es bei der 
> Umrechnung zwischen den Systemen zu Ungenauigkeiten im Bereich von drei 
> Metern (wenn ich mich nicht verrechnet habe)?
> Wie kommen die Vermessungsämter eigentlich auf ihre GK-Koordinaten? Passiert 
> das schon im Empfänger?
>
> Ciao,
> Miriam


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

Re: [Talk-de] Gauß-Krüger > WGS-84

[Stefan Dettenhofer (StefanDausR)]

Hallo Markus,

ich hatte mal für Regensburg folgende Werte bestimmt:
 
Im Rechtswert (GK) entsprechen 10 Meter  0,49'' (WGS-84)
Im Hochwert   (GK) entsprechen 10 Meter  0,33'' (WGS-84)

Noch war zur "Koordinatenverwirrung", da ich gerade mal wieder die 
DatRi-GRUBIS vor mir liegen habe, die den Datenaustausch der 
Vermessungsämter regelt:

Feld 8: Rechtswert oder y-Wert
Der jeweilige Rechtswert oder y-Wert wird in der Maßeinheit Zentimeter 
dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der 
Meridiankennziffer. Führende Nullen werden angegeben.
Feld 9: Hochwert oder x-Wert
Der jeweilige Hochwert oder x-Wert wird in der Maßeinheit Zentimeter 
dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der 1000 km-Stelle. 
Führende Nullen werden angegeben.

Also bei GK-Koordinaten sollte man immer vom Rechts- bzw. Hochwert 
sprechen, da die Vermesser X-Achse und Y-Achse anders sehen als die 
Normaluser!


Markus schrieb:
> Hallo Miriam,
>
>   
>> das gleiche Ergebnis 
>> 
>
> Ja, das hat mich auch irritiert.
> Damit ich eine Vorstellung der Differenzen bekomme, habe ich eine 
> Tabelle gemacht, wieviel Nachkommastellen wie genau sind:
> http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten
> (kann das bitte mal jemand prüfe?)
>
> Bei Deinen Beispielen beträgt die max. Abweichung
> Breite: 3,12m
> Länge:  4,35m*cos(Breite)=2,8m
> (wenn ich richtig gerechnet habe)
>
> Es würde also bei der dezimalen Koordinaten-Darstellung reichen, wenn 
> man 5 Nachkommastellen angibt (der Rest gaukelt eine nicht vorhandene 
> Genauigkeit vor). Und das gilt natürlich auch nur, wenn die 
> ursprünglichen Messergebnisse vor der Umwandlung so genau waren.
> (in diesem Falle hat man mir 1 dm genannt)
>
> 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] Luftbilder Bayern / Strassenverzeichnis

[Stefan Dettenhofer (StefanDausR)]

Hallo Martin,

sollten denn nicht hier
http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis#Bayern
alle Anfragen bzgl. SV eingetragen werden?
Da wäre es gut, wenn auch alle nicht beantworteten und abgelehnten 
Anfragen eingetragen würden. Auch wenn es nur Daten in Papierform (für 
welche Nutzung?) gibt, sollte das mit rein!

Gruß,
Stefan

Martin Trautmann schrieb:
> Für alle: Ein Anschreiben aller Bayrischen Gemeinden hatte ich bereits 
> 2006 einmal gemacht, um Straßenverzeichnisse zu bekommen. Das kann ich 
> gerne für die Oberpfalz wiederholen, wüsste dann aber gerne, wo ich 
> nicht nochmals hinschreiben soll.
>
> Meine Anfrage wurde in der Regel vom Einwohnermeldeamt beantwortet, von 
> wo ich die bewohnten Anschriften bekommen konnte. Weitere Straßen sind 
> eher zufällig dabei. Diese Info über alle Wege bekommt man eher vom 
> Katasteramt - dort aber oft nicht kostenfrei.
>
> Damals bekam ich übrigens leider sehr oft nur Papierausdrucke zurück. 
> Die verwende ich zur Einzefallprüfung, habe aber nicht konsequent alles 
> daraus abgetippt. Meine eigene OCR-Ausstattung ist dafür viel zu schwach.
>   


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

Re: [Talk-de] Durchgehende Kartengenerierung basteln (Windows)

[Stefan Dettenhofer (StefanDausR)]

Hallo Jan,

ich mach das so ähnlich mit Kosmos (MaxSpeed-Karte) bzw. den 
NaviPOWM-Karten.
Wo ist genau das Problem? Du kannst doch mit der call-Anweisung eine 
andere BAT-Datei aufrufen. Du musst nur aufpassen, dass Du immer im 
richtigen Arbeitsverzeichnis bist.

Gruß,
Stefan

Jan Tappenbeck schrieb:
> Zunächst hatte ich die einzelnen Schritte in einzelnen Verzeichnissen 
> abgelegt und das hat auch geklappt. Dann wolle ich alles in einem Batch 
> ausführen (Faulheit) und da bin ich am aufrufen der unterschiedlichen 
> "Sub"-Batchroutinen gescheitert.
>   


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

Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschriebe n - Bildqualität?

[Stefan Dettenhofer (StefanDausR)]

Hallo,

ich habe mir gerade die Bilder von meinem Haus in JOSM (mit WMS-Plugin) 
angesehen und mit den Original 2m-Luftbildern des LVA verglichen.
z.B. hier http://stadtplan.regensburg.de/
Der Qualitätsunterschied ist ja sehr groß! Sind die Quelldaten nicht 
besser oder passiert der Qualitätsverlust bein Transformieren oder 
stelle ich mich nur zu dumm an?
Einzelne Häuser sind eigentlich nicht erkennbar.

Gruß,
Stefan

Sven Geggus schrieb:
> Markus  wrote:
>
>   
>> Sven Geggus wird den WMS-Server aufsetzen und die Daten ggf. in
>> unser Format transformieren.
>> 
>
> Falls es der ein oder andere hier überhaupt nicht abwarten kann die
> "Tirschenreuther Teichpfanne" abzuzeichnen ;)
>
> Ab sofort läuft der WMS-Server!
>
> Im josm WMS Plugin einfach folgende URL eintragen
> (das "?" ist wichtig):
> http://oberpfalz.geofabrik.de/wms4josm?
>
> Die Adresse des richtigen[tm] WMS Servers lautet
> http://oberpfalz.geofabrik.de/wms
>
> Die Konvertierung der Tiles für Potlach läuft derzeit noch, aber da sind
> mir auch in gewisser Weise die Hände gebunden, das muss der Author
> von Potlach einbauen.
>
> Authoren anderer OSM Editoren melden sich bitte per Email bei mir.
>
> Gruss
>
> Sven
>
>   



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

Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschriebe n - Bildqualität?

[Stefan Dettenhofer (StefanDausR)]

mea culpa!

Ich war davon ausgegangen, dass die Orthofotos im Bayernviewer auch nur 
2m Bodenauflösung hätten, das ist aber nicht so. (Und die Bilder die mir 
vorliegen haben 0,2m Bodenauflösung...)

Nochmals Entschuldigung!
Stefan

Sven Geggus schrieb:
> "Stefan Dettenhofer (StefanDausR)"  wrote:
>
>   
>> Der Qualitätsunterschied ist ja sehr groß! Sind die Quelldaten nicht 
>> besser oder passiert der Qualitätsverlust bein Transformieren oder 
>> stelle ich mich nur zu dumm an?
>> 
>
> Vermutlich beides :) Das WMS Plugin vom josm lädt die Bilder in
> besserer Qualität wenn man weiter reinzoomt. Ansonsten ist die
> Qualität leider wirklich nicht zum abmalen von Häusern geeignet. Da
> hätten wir Bilder mit 50cm Auflösung benötigt. kannst Du Dir ja
> leicht ausrechnen. Wenn ein Haus zum Beispiel 10mx10m ist, dann sind
> das ja gerade mal 5x5 Pixel.
>
> Gruss
>
> Sven
>
>   



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

Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

Hallo Miriam,

also ich finde, dass die Luftbilder in dem Bereich schon recht gut mit 
den bereits erfassten Straßen übereinstimmen. Es kann immer wieder 
einmal Abweichungen geben, aber eine größere absolute Genauigkeit, als 
5-10m werden wir mit den verfügbaren Daten und GPS-Geräten nicht 
hinbekommen.
Im Zweifelsfall würde ich mich auf mehrere GPS-Traces verlassen, denn 
eine ganz genaue Georeferenzierung der Luftbilder ist nicht so einfach 
zu bewerkstelligen. Eine lokale Verschiebung um ein paar Meter wird es 
da immer geben. Abweichungen in dieser Größenordnung ergeben sich ja 
schon bei den unterschiedlichen Umrechnungsverfahren (Parametern) von GK 
nach WGS-84.

Gruß,
Stefan


Miriam Tolke schrieb:
> Hallo,
>
> anläßlich der Verfügbarkeit der neuen Luftbilder wollte ich mir gerade mal 
> angesehen wie sich die mit denen von Yahoo und Google decken.
> Mangels Yahoo-Abdeckung in der Oberpfalz habe ich einen Punkt in Google Earth 
> gesetzt und in JOSM eingeladen.
> Aus Erfahrung weiß ich, dass
> 1. Punkte in Google Earth/Maps ca. 2m weiter südlich und 2m weiter östlich 
> liegen als meine GPS-Punkte.
> 2. Punkte in Yahho-WMS-Bildern ca. 4m weiter südlich und 4m weiter östlich 
> liegen als meine GPS-Punkte.
>
> Verglichen mit dem Punkt aus GE liegen die LVA-Luftbilder ca. 7m nach Süden 
> und 5m nach Osten verschoben.
> Und nachdem ich mir einige GPS-Traces in Regensburg über die LVA-Luftbilder 
> gelegt habe (meine Erachtens schön zu sehen z.B. an Frankenstraße mit 
> dengetrennten Fahrbahnen oder auch Am Europakanal), liegen die auch alle 
> zumindest weiter nördlich als sie den Luftbildern nach sollten.
>
> Ist das im Import passiert, oder sind die beim LVA schon so?
> Klar wird gesagt GPS ist im Bereich von 10m ungenau. Nur zeigt meine 
> Erfahrung, dass es ziemlich konstant 2-3m von den Google-Bildern sind. 
> Außerdem halte ich es für unwahrscheinlich dass die Mehrzahl der 
> OSM-GPS-Traces um den selben Wert abweichen.
>
> Grüße,
> Miriam
>   


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

Re: [Talk-de] NEUGIER

[Stefan Dettenhofer (StefanDausR)]

... und auch die, die Punkte verschieben oder mit Ortskenntnis Attribute 
hinzufügen...

Stefan

Guenther Meyer schrieb:
> Am Sonntag 14 Dezember 2008 schrieb Gary68:
>   
>> ich war heute neugierig und habe mal geschaut, wer so alles mitmacht in
>> der oberpfalz (ich hoffe, man kann es lesen):
>>
>> sind doch ein paar fleißige dabei!
>>
>> 
> na toll...
> und die, die schon in der oberpfalz gemappt, als es noch nicht interessant 
> war, fallen dabei voellig unter den tisch, gruml... ;-)
>   


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

Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

so einfach ist das mit dem Umrechnen auch nicht! Auf wenige Meter genau 
ist es kein Problem, aber wenn man es genauer will, wird es kompliziert. 
Vor allem dann, wenn man nicht weiß, welche Parameter nun hier gültig sind.
Die Vermessungsämter arbeiten -so weit ich weiß- nur mit GK-Koordinaten 
und daher stellt sich das Problem nicht.
Wird mit GPS gearbeitet, so kann man sich immer auf einen genauen 
Referenzpunkt beziehen und die Messergebnisse dann damit einpassen.
Eine flächendeckende und exakte Umrechnung wird es wohl nicht geben.
Ein weiteres Problem ergibt sich ja aus der Verzerrung des Luftbildes 
selbst. Diese sind ja nicht auf unendlicher Höhe aufgenommen, daher gibt 
es an den Rändern der Einzelaufnahmen Verzerrungen. Das gesamte 
Orthofoto wird ja aus Einzelaufnahmen zusammengesetzt, die miteinander 
verrechnet und ausgeglichen werden müssen. Dieser Ausgleich müsste 
eigentlich auch noch auf die Höhe (ü. NN) ausgedehnt werden, denn beim 
Überflug mit konstanter Höhe ändert sich ja die Höhe über Grund und so 
werden höherliegende Orte größer dargestellt als tieferliegende.

Gruß,
Stefan

Markus schrieb:
> Dann in WGS-84 umrechnen:
> http://wiki.openstreetmap.org/wiki/Gauß-Krüger
> und mit dem neuen JOSM-Tool "+node" einzeichnen,
> und mit den Daten und Luftbildern vergleichen


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

[Talk-de] Wanderwege war: nochmal LKW-Routing

[Stefan Dettenhofer (StefanDausR)]

Ich hatte mal versucht mit Kosmos einen Relations-Overlay zu machen, um 
Wanderwege etc anzuzeigen.
Das geht schon, aber man kann noch nicht gut Attribute der Relationen 
darstellen sondern nur die der Wege, daher habe ich noch nicht 
weitergemacht.

Gruß,
Stefan

Sven Geggus schrieb:
> Markus  wrote:
>
>   
>> Der Fränkische Albverein ist schon mal sehr an OSM interessiert.
>> Sie pflegen alle Wanderwege und haben dazu die Tracks und möchten die 
>> gern in OSM darstellen (haben aber niemanden, der weiss wie das geht).
>> 
>
> Wenn man SAC-scale Markierungen an Wege dranmacht werden die zumindest in
> Osmarender gerendert.
>
> Sven
>
>   



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

Re: [Talk-de] LKW-Routing (TV-Bericht)

[Stefan Dettenhofer (StefanDausR)]

Hallo Garry,

mir ging es nur darum, ob es ein Lizenzproblem (CC 2.0) mit den 
OSM-Daten geben könnte. Das es andere vertragliche Schwierigkeiten geben 
kann, steht auf einem anderen Blatt.

Gruß,
Stefan

Garry schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Wieso? Man könnte doch die kommerziellen Daten strikt von den OSM-Daten 
>> trennen (2 unterschiedliche Dateien), die dann erst im Naviprogramm 
>> zusammengeführt werden.
>> Die OSM-Daten könnten dabei frei downloadbar sein.
>>
>> Wo ist da ein Lizenzproblem?
>>   
>> 
> Ein Lizensproblem dürfte von daher bestehen dass ein kommerzieller 
> Kartenanbieter nicht oder nur zu wesentlich schlechteren Konditionen 
> zulassen wird dass fremdes Kartenmaterial
> aufgespielt werden kann - durch entsprechende Knebelverträge.
>
> Garry
>   


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

Re: [Talk-de] genauer Online-Transformator für Mark us & OSM

[Stefan Dettenhofer (StefanDausR)]

Zur Vollständigkeit:

Stefan (GEOTRANS) : 51.4695998808, 6.7921828940
> Tobias (NRW) : 51.4696196309, 6.79221558802
> Tobias (complete): 51.4696117875, 6.79223525397
> Tobias (BeTA2007): 51.4696152617, 6.79221329054
> Tobias (Proj.4)  : 51.4695741927, 6.79225058706
>
> Frederik (Proj.4): 51.470929, 6.7929530


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

Re: [Talk-de] genauer Online-Transformator für Mark us & OSM

[Stefan Dettenhofer (StefanDausR)]

Ohne es genauer geprüft zu haben, sieht es so aus, als ob Du in 
EPSG:4314 (Potsdam-Datum) umgerechnet hättest, also geografische 
Koordinaten ohne Ellipsoidübergang.

Stefan

Frederik Ramm schrieb:
> Das ist eine Abweichung von 0.00131 in der Breite und 0.000738 in der
> Länge, oder auch rund 150 Meter. Kann proj.4 wirklich so daneben liegen?
>
> Bye
> Frederik


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

Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

Die Gebührenordnung gibt es sogar online (Pos. 2.10.1):
http://online-service.nuernberg.de/eris/downloadPDF.do;jsessionid=95E0C60B88A4C8F286789E017F196AAB?id=334134

Stefan

Miriam Tolke schrieb:
> Der Mitarbeiter sieht sich für die Auskunft "an die Vorgaben unserer 
> Gebührensatzung gebunden".
>


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

Re: [Talk-de] genauer Online-Transformator für Marku s & OSM

[Stefan Dettenhofer (StefanDausR)]

Ja, die einfache 3-Parameter-Transformation mit diesen Werten:

static double WGS84_f = 1 / 298.257223563;  /* Flattening of 
WGS84 ellisoid */

/* Ellipsoid Parameters, Bessel  */
static double Bessel_a = 6377397.155;/* Semi-major axis 
of ellipsoid in meters */
static double Bessel_f = 1 / 299.152812800;  /* Flattening of 
ellipsoid  */

// GK_2
double Origin_Latitude = 0.0;
double Central_Meridian = PI * 6.0 / 180.0;
double False_Easting = 250.0;
double False_Northing = 0.0;
double Scale_Factor = 1.0;

// *POT"Potsdam/Rauenberg"  BR  587   -1   16   -1   
393   -10   800   18
double dx = 587;
double dy = 16;
double dz = 393;


Hast du die Werte für die 7-Parameter-Transformation?

Gruß,
Stefan


Tobias Wendorff schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> Stefan (GEOTRANS) : 51.4695998808, 6.7921828940
>> 
>
> Gehst Du von den "alten" DE-Complete Shiftwerten aus?
>   


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

Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

Mit google:
http://www.google.de/search?hl=de&q=H%C3%B6henfestpunktverzeichnis+n%C3%BCrnberg&btnG=Google-Suche&meta=

Gruß,
Stefan

Miriam Tolke schrieb:
> Stefan Dettenhofer schrieb am Mi, 17.12.2008:
>
>   
>> Die Gebührenordnung gibt es sogar online (Pos. 2.10.1):
>> 
>
> Ups, wie hast Du die denn gefunden? Ich hatte es mehrfach versucht (sowohl 
> über die Navigation als auch die Sitesuche).
>
> Tobias hat schon recht, schauerlich.
>
> Danke,
> Miriam


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

Re: [Talk-de] Ortsgebiet

[Stefan Dettenhofer (StefanDausR)]

Oh, interessant!
Gibt es da schon nähere Infos zu Deinem Programm? Auf welcher Plattform 
soll es laufen?
Ich kenne nur NaviPOWM und nutze es um OSM-Daten vor Ort zu sehen.

Gruß,
Stefan

Marcus Wolschon schrieb:
> Kleiner Hinweis:
>
> Ich schreibe an einem Navi, Was meinst du warum ich hier so hinterher bin
> mit eindeutig und automatisch zu interretierbaren Daten und so.
> Momentan debugge ich meine Referenz-Implementierung für das neue
> osmbin-Format um auf dem CCCongress ein nutzbares Navi zeigen zu können.
>
> Marcus


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

[Talk-de] ETRS89 <-> WGS84 war: Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

Hallo Christian,

ich habe mich gerade nochmals in der EPSG-Datenbank umgesehen und 
festgestellt, dass dort ETRS89 (EPSG:4258) und WGS84 (EPSG: 4326) als 
"identisch" (Unterschied<1m) betrachtet wird. Zumindest gelten bei der 
Umrechnung die selben Parameter.

ETRS89 verwendet das Ellipsoid GRS80 , gilt europaweit und ist mit dem 
festen Teil der eurasischen Platte verankert.
WGS 84 verwendet das Ellipsoid WGS84, gilt weltweit und benutzt feste 
Stationen.

Für die Koordinatentransformation ETRS89 -> WGS 84 (EPSG:1149) werden 
keine Parameter angegeben, da der Unterschied kleiner als 1m ist.
Hat Du hier eine Umrechnungsvorschrift, die die Plattentektonik 
berücksichtigt? Den Ellipsoidübergang (GRS80->WGS84) könnte man ja 
realisieren.

Warum ich das frage:
Die wohl genaueste Transformation von DHDN nach ETRS89 ist die BeTA2007 
(EPSG:15948).
Für die Transformation DHDN nach WGS84 (EPSG:15949) wird aber die selbe 
Gitterdatei benutzt.
(In der EPSG-Datenbank wird aber auch nur eine Genauigkeit von 1m angegeben)

Das selbe gilt für die Transformationen (hier wird eine Genauigkeit von 
0,1m genannt):
DHDN -> ETRS89 nord (EPSG:1780) gültig: lat>52°20'
DHDN -> ETRS89 mitte (EPSG:1779) gültig: 50°20' ETRS89 süd (EPSG:1779) gültig: lat<50°20'
Hierzu gibt es aber keine äquivalenten Umrechnungen DHDN -> WGS84

Ich frage mich dann nur, was bringt überhaut die genaueste Umrechnung 
von GK-Koordinaten nach ETRS89, wenn wir ja eigentlich WGS84 brauchen, 
dabei aber wieder Abweichungen bis zu 1m haben?

Gruß,
Stefan

 
Chris66 schrieb:
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> so einfach ist das mit dem Umrechnen auch nicht! Auf wenige Meter genau 
>> ist es kein Problem, aber wenn man es genauer will, wird es kompliziert. 
>> Vor allem dann, wenn man nicht weiß, welche Parameter nun hier gültig sind.
>> Die Vermessungsämter arbeiten -so weit ich weiß- nur mit GK-Koordinaten 
>> 
>
> Die TPs, welche ich für meine Gegend mal bekommen habe waren bereits
> alle in ETRS-89 umgerechnet. Und bei deren Umrechnung in WGS-84
> muss man dann noch die Plattentektonik berücksichtigen, das
> machen nicht alle Programme. Derzeitiger Shift: ca. 50 cm
> (2 cm pro Jahr).
>
> Grüße,
> Christian
>
>
> ___
> 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] ETRS89 <-> WGS84 war: Lagegenauigkeit der LVA-Luftbilder

[Stefan Dettenhofer (StefanDausR)]

Das stimmt aber nur in Bezug auf das Ellipsoid, nicht auf die 
Plattentektonik! Die derzeit ca. 50cm bleiben trotzdem als zusätzlichen 
Unterschied zwischen ETRS89 und WGS84.

Stefan

Tobias Wendorff schrieb:
> ETRS89 und WGS84 unterscheiden sich *MINIMALST*
>
> WGS84:
> Umfang Äquator: 6.378.137,0 m
> Erdabplattung: 1/298.257223563
>
> ETRS89 verwendet GRS80 als Referenzellipsoiden:
> Umfang Äquator: 6.378.137,0 Meter
> Erdabplattung: 1/298.2572221
>
> (1/298,257223563) - (1/298,2572221) = Rundungsfehler :-)
>   


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

Re: [Talk-de] NaviPOWM 0.2.0 freigegeben

[Stefan Dettenhofer (StefanDausR)]

Die neuen Karten für Deutschland befinden sich hier:

http://wince.dentro.info/koord/osm/TileMap.htm

Gruß,
Stefan

Doru Julian Bugariu schrieb:
> Hallo,
>
> die neue Version von NaviPOWM (0.2.0) ist freigegeben. Sie befindet sich
> an der ueblichen Stelle:
>
> http://sourceforge.net/projects/navipowm
>
> Hier ganz kurz ein paar der Unterschiede zur 0.1.3:
>
> behobene Bugs:
> - Absolute Pfade im DEMO Modus haben nicht richtig funktioniert
> - Fehler in der Darstellung behoben
>
> implementierte Feature Requests:
> - Start mit der letzten GPS-Position moeglich
> - Unter Windows Mobile kann das Abschalten des Geraets verhindert werden
> - "snap to way" einstellbar
> - Die Schriftgroesse fuer die Anzeigen ist konfigurierbar
> - Darstellung erfolgt jetzt deutlich schneller
> - zahlreiche andere kleinere Aenderungen
>
> anderes:
> - Komplett neues Kartenformat (1° x 1° Kacheln)
> - Detail-Level jetzt vom Zoom abhaengig
> - Ein "Hinterherhinken" des GPS-Empfaengers kann jetzt kompensiert werden.
>
>
> Wichtig: die alten Karten koennen *nicht* weiterverwendet werden!
>
>
> Ich wuensche Euch viel Vergnuegen mit der neuen Version.
>
>
>
> Gruesse,
> Julian
>
>   



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

Re: [Talk-de] TMC

[Stefan Dettenhofer (StefanDausR)]

Hallo,

Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort 
bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen 
Infos und Daten.

Übertragen wird bei TMC nur der sog. location-code, der angibt, wo eine 
Störung beginnt und auf wie viele Abschnitte er sich erstreckt. 
Weiterhin wird ein event-code übertragen, der angibt, was los ist.

Die Eventliste findet man im Internet auch. Die location-codes werden 
eben von der BAST vergeben und definieren "wichtige" Abschnitte. Also 
z.B. bei einer Autobahn normalerweise die Strecke zwischen zwei 
Ausfahrten oder auch ein Tunnel. Es gibt auch codes für Bundes und 
Landstraßen und wichtige andere Straßen (teilweise auch innerorts). Die 
"locations" sind aber auch in der Liste mit Koordinaten hinterlegt, so 
dass man sie auf einer Karte anzeigen könnte.

Gruß,
Stefan

Bernd Wurst schrieb:
> Hallo.
>
> Halbwegs off-topic, aber ich hoffe mal, jemand weiß dazu etwas...
>
> Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, 
> besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt 
> auf die Straßenabschnitte projeziert werden?
>
> Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich 
> nicht glauben mag, dass die TMC-Daten Freitext a la "A8 zwischen Kreuz 
> Stuttgart und Dreieck Leonberg"  enthalten sondern ich würde erwarten, dass 
> es 
> da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben.
>
> Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten 
> theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon?
> Oder ist das alles prorietär, keiner weiß was davonund man kann sich die 
> Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-)
>
> Gruß, Bernd
>
>   
> 
>
> ___
> 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] Track-Anonymisierer gesucht

[Stefan Dettenhofer (StefanDausR)]

Johann H. Addicks schrieb:
> (...)
> Mir geht es darum, dass ich viele Kollegen habe, die derzeit mit Geräten  
> herumfahren (Tomtom, GoPal), die problemlos in der Lage wären, Tracklogs zu  
> nehmen.
(...)

Für die "GoPal-Leute" könnte ich ggf. mein Programm Koord465 
http://wiki.openstreetmap.org/wiki/User:StefanDausR
entsprechend erweitern, indem ich z.B. vom Datum z.B. 20 Jahre abziehe, oder 
so. Dann würde das ganze gleich auf dem PNA laufen.
Um aus den TRK-Dateien GPX zu machen muss ich sowieso erst das Datum aus dem 
Dateinamen und der Zeit zusammensetzten.

Wenn also Bedarf in dieser Richtung besteht, kannst Du dich ja bei mir nochmals 
melden.

Gruß,
Stefan




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

Re: [Talk-de] Track-Anonymisierer gesucht

[Stefan Dettenhofer (StefanDausR)]

Hallo Marcus,

eine Wiki-Seite kenne ich nicht, außer der Doku natürlich
http://www.topografix.com/GPX/1/1/
aber das ist nicht so viel:
Damit die GPX-Dateien angenommen werden, müssen sie namen den 
Koordinaten nur den (einen) Zeitstempel haben. Alles Weitere (Höhe, 
Geschwindigkeit, etc.) muss nicht vorhanden sein.

Ich denke aber, dass sich für solche Dateien auch z.B. das Attribut 
"creator" im Header eignen würde, also z.B. creator=anonym
Allerdings weiß ich nicht, ob diese Info in der Datenbank abgespeichert 
wird.

Gruß,
Stefan


marcus.wolsc...@googlemail.com schrieb:
> On Wed, 07 Jan 2009 12:53:12 +0100, "Stefan Dettenhofer (StefanDausR)"
>  wrote:
>   
>> Für die "GoPal-Leute" könnte ich ggf. mein Programm Koord465
>> http://wiki.openstreetmap.org/wiki/User:StefanDausR
>> entsprechend erweitern, indem ich z.B. vom Datum z.B. 20 Jahre abziehe,
>> oder so. Dann würde das ganze gleich auf dem PNA laufen.
>> Um aus den TRK-Dateien GPX zu machen muss ich sowieso erst das Datum aus
>> dem Dateinamen und der Zeit zusammensetzten.
>>
>> Wenn also Bedarf in dieser Richtung besteht, kannst Du dich ja bei mir
>> nochmals melden.
>> 
>
>
> Haben wir irgendwo eine Wiki-Seite,
> auf der Tags für GPX-Traces gesammelt sind?
> Um die Tracks nachher als "anonymisiert" zu taggen.
>
> Marcus
>   


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

Re: [Talk-de] Karte mit Öffentlichen Verkehrsmitteln

[Stefan Dettenhofer (StefanDausR)]

Hallo,

Melchior Moos schrieb:
> Das ist, weil die Zoomstufen ab 14 aufwärts nur auf Anfrage gerendert 
> werden. Das spart tüchtig Zeit beim Rendern und viel Speicherplatz.
Wie hast Du das denn serverseitig gelöst?

Gruß,
Stefan


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

[Talk-de] Sonnenkompass - war:Fehlende Straß en/Wege/Pfade

[Stefan Dettenhofer (StefanDausR)]

Hallo,

ich habe einen "Sonnenkompass" für meinen PNA (Medion/GoPal) 
programmiert, siehe hier:
http://forum.pocketnavigation.de/tid1103041-sid.htm

Gruß,
Stefan

Jan-Benedict Glaw schrieb:
> On Sat, 2009-01-10 09:30:04 +0100, Jan Tappenbeck  wrote:
>   
>> Vielleicht zusätzlich mit einer kleinen Funktion im Editor. Node 
>> definieren und Richtung vorgeben - den Rest, einschl. Länge, zeichnet 
>> der Editor !
>> 
>
> Genau das ist mein Ziel.
>
> Ich hab' übrigens mittlerweile angefangen, mittels Laptop und Sonne
> einen Sonnenkompaß zu programmieren: Rechner in Richtung des Weges
> halten und mit dem Mausrad oder den Cursor-Tasten einen Pfeil in
> Sonnenrichtung drehen.
>
> Zusammen mit der Ortsangabe (GPS) sollte man so in etwa auf die
> Richtung kommen.
>
> MfG, JBG


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

Re: [Talk-de] Osmosis-Fragen

[Stefan Dettenhofer (StefanDausR)]

Hallo Detlef,

also ich zerschneide die germany.osm regelmäßig in 1°x1°-Stücke, damit 
ich die Karten für NaviPOWM berechnen kann. Das läuft aber in ca. 2-3 
Stunden auf Dateiebene durch. Ganz Europa dauert so einen halben Tag.

Ich mache das aber 2-stufig:
Zuerst schneide ich 1°-Streifen heraus, die ich dann in einem 2. 
Durchlauf nochmals zerstückele.
Außerdem benutze ich enableDateParsing="no"

Gruß,
Stefan



Detlef Reichl schrieb:
> Am Freitag, den 09.01.2009, 22:44 +0100 schrieb Frederik Ramm:
>   
>> Hallo,
>>
>> Detlef Reichl wrote:
>> 
>>> ich versuche grade mit Hilfe von Osmosis die Baden-Württemberg OSM-Datei
>>> von der geofabrik in Zoom-Level 12 große Stücke zu schneiden. Insgesamt
>>> werden es 1435 einzelne Tiles und mein - nicht mehr wirklich neuer -
>>> Rechner wird wenn er fertig ist damit rund zwei Tage zugebracht haben.
>>> Momentan läuft das bei mir einfach auf Dateiebene.
>>>   
>> Du weisst, dass
>>
>> 1. Osmosis superlangsam beim Lesen/Schreiben von .bz2 ist? Also immer in 
>> rohe .osm schreiben bzw. aus rohen .osm lesen und vorher/nacher die 
>> Kompression!
>>
>> 
> Hallo Frederik,
>
> danke fürs feedback. Um die Kompression bin ich elegant drumrum
> geschifft, indem ich es vorher entpackt habe. Die Hinweise zur
> bz2-Performanz hatte ich gelesen.
>
>   
>> 2. Osmosis mehrere Excerpte in einem Rutsch machen kann, indem Du den 
>> mit --rx gelesenen Datenstrom mit --tee splittest und dann jeweils 
>> Pärchan von --bb und --wx anhängst? 1435 wird nicht gehen, aber wenn Du 
>> in Schritt 1 Ba-Wue in Level-9-Happen zerteilst und jeden davon in 
>> Schritt 2 wieder in 64, kämst Du mit 65 Osmosis-Aufrufen hin.
>>
>> 
> Momentan verarbeite ich es Zeilenweise, 41 Zeilen a 35 Tiles. Da stellte
> ich mir schon die Frage, ob es nicht sinnvoller wäre es mehr in einer
> Art Schachbrettmuster zu verarbeiten. Die Cance, die Daten die benötigt
> werden um ein Tile fertig zu stellen, im RAM zu finden dürfen dann
> größer sein.
>
>   
>>> Ich frage mich jetzt, ob wenn ich die Daten erst in eine DB schreiben
>>> würde, Geschwindingkeitsvorteile erzielen würde. Außerdem, ist das bei
>>> einem GB RAM überhaupt praktikabel (mehr lässt sich in den Rechner
>>> leider nicht einbauen)?
>>>   
>> Hm, bist Du ueberhaupt sicher, dass Du diese vorberechneten Kacheln 
>> brauchst?
>> 
>
> Da komme ich nicht drum herum. Diese Kacheln dienen als Basis für eine
> Slippy-Map, die die Daten für POIs dynamisch Kachelweise nachläd, als
> Basis für Fehlerkarten und Dauer wahrscheinlich noch für das eine oder
> andere mehr.
>
>   
>> Koenntest du nicht einfach die komplette OSM-API (oder einen 
>> "ROMA"-Server, s. Wiki) bei Dir installieren und dann einfach mit einem 
>> "map"-Aufruf jeweils lokal den Bereich abrufen, den Du brauchst?
>>
>> 
> Mit ROMA hatte ich mich bislang noch nicht befasst. Ist es damit auch
> möglich einzelne Teilbereiche "anzubieten" und nicht nur das komplette
> "planet.osm"?
>
>   
>>> Gibt es neben Osmosis vielleicht noch eine Alternative? Wichtig ist, das
>>> alle Daten übertragen werden. osmcut, das Relationen nicht berücksichtig
>>> scheidet deshalb schon mal aus.
>>>   
>> Bau doch Relationen in osmcut ein, das ist keine Magie. (Du weisst, dass 
>> Du bei Osmosis spezielle Commandline-Switches brauchst, wenn Du willst, 
>> dass auch aussenliegende Member von Relationen und Ways mit ausgegeben 
>> werden, und dass dadurch alles noch langsamer wird?)
>> 
>
> osmcut zu erweitern hatte ich auch schon drüber nach gedacht. Das
> scheiterte allerdings bislang am inneren Schweinehund ;-) Warum etwas
> selbst programmieren, wenn es schon brauchbare Alternativen gibt.
> Wahrscheinlich werde ich mir das aber doch nochmals anschauen. Die
> Laufzeiten von osmosis sind mir einfach zu lang.
>
> Über die Kommandozeilenoptionen von Osmosis weiß ich Bescheid, und ich
> vermutete auch schon, das diese zu der (nicht berauschenden)
> Geschwindigkeit beitrugen.
>
> Grüßle, detlef
>
>
>
>
>
>
> ___
> 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] Rendern eines Spielfeldes

[Stefan Dettenhofer (StefanDausR)]

Hallo zusammen,

kann mir jemand sagen, was ich hier falsch mache?

So ist es richtig gerendert, man sieht beide Fußballfelder:
http://www.informationfreeway.org/?lat=49.069687825955505&lon=12.045638974751668&zoom=17&layers=BF000F

Und hier fehlt ein Fußballfeld:
http://www.informationfreeway.org/?lat=49.069687825955505&lon=12.045638974751668&zoom=17&layers=0F0B0F

Gruß und Danke,
Stefan


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

Re: [Talk-de] Rendern eines Spielfeldes

[Stefan Dettenhofer (StefanDausR)]

Hallo Mario,

danke, da hätte ich auch d'aufkommen können!

Gruß,
Stefan

DarkAngel schrieb:
> Bei dem linken Feld hat eine Begrenzungslinie gefehlt. An der Stelle, wo
> Fußballfeld und Tennisfeld aneinander grenzen, war nur die Linie des
> Tennisfeldes. Somit war das Fußballfeld nicht vollständig umrandet und
> wurde von Mapnik nicht gerendert. Nun sollte es passen...
>
> - --
> Gruß Mario


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

Re: [Talk-de] Brücken- und Tunnelnamen

[Stefan Dettenhofer (StefanDausR)]

Hallo Jan,

ich denke, das kommt darauf an, was man als Ergebnis haben will:
Auf der Karte soll doch der Name der Brücke stehen und im Navi will ich 
auch diesen angezeigt haben.

Daher spricht meinerseits nichts dagegen, diesen in NAME zu schreiben. 
Der Weg muss so und so aufgeteilt werden.
Natürlich wäre ein extra Tag noch sauberer, aber man kann ja auch "die 
Kirche im Dorf" lassen.

Ich weiß, das wir nicht für die Renderer und Navis taggen, aber auch 
nicht nur für die Datenbank!

Alternative:
Straße wird einer Relation zugefügt, diese erhält als name= den Namen 
der Straße. Der Way erhält gar keinen Namen. Nur die Brückenabschnitte 
etc. werden explizit auf dem way benamt.

Gruß,
Stefan


Jan Tappenbeck schrieb:
> Moin  !
>
> wir diskutieren gerade darüber wie es sich mit Tunnel- bzw. Brückennamen 
> verhält.
>
> Eine Straße hat das Tag NAME welche in der Regel den Namen der Straße 
> bekommt - z.b. Autovía del Mediterráneo
>
> Jetzt wird diese Trasse von benannten Brücken und Tunnel durchzogen die 
> allesamt eigene Namen haben.
>
> Wenn jetzt das Tag NAME den Namen des Tunnels bekommt ist das unsauber, 
> da die dort entlang führende Straße immer noch Autovía del Mediterráneo 
> heißt 
>
> Richtig müßt die Ergänzung durch folgende Tags sein...
>
> tunnel_name=Torrox
> oder
> bridge_name=Köbrandbrücke
>
> Diese Konstellation gibt es eigentlich überall und deshalb sollte hier 
> vielleicht eine entsprechende Regelung getroffen werden.
>
> Wie denkt Ihr darüber und gibt es vielleicht andere Ideen und Ansätze.
>
> Gruß Jan :-)
>
> ___
> 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] Taggen einer Winterrodelbahn

[Stefan Dettenhofer (StefanDausR)]

Michael Buchberger schrieb:
> Hallo Manuel,
>
> Markus schrieb:
>   
>> hier findest Du ein Beispiel:
>> http://www.openstreetmap.org/edit?lat=47.05303&lon=8.48042&zoom=17
>>   
>> 
>
> Ich habe Anfang der Woche dies eingegeben:
>
> http://www.openstreetmap.org/?lat=49.27928&lon=7.86255&zoom=16&layers=0B00FTF
>
> Einfach einen Way mit piste:type=sled und dann wird das ganze schon im
> Osmarender angezeigt.
>
> Tschuess
>  Michael
>
>   
... oder hier:
http://www.informationfreeway.org/?lat=49.07061563138182&lon=12.050348932761672&zoom=17&layers=BF000F
leider wird mir da die ganze Grünfläche überdeckt!

Gruß,
Stefan


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

Re: [Talk-de] Taggen "Gemeinsamer Rad- und Fußweg "

[Stefan Dettenhofer (StefanDausR)]

Hallo Helmut,

ich verwende highway=path eigentlich nur für Wanderwege und Trampelpfade 
(außerorts).
Für beschilderte (Zeichen 240) Fußwege nehme ich lieber highway=footway. 
Analoges gilt für highway=cycleway.

Gruß,
Stefan

Helmut Vogel schrieb:
> Hallo,
>
> ich bin gerade dabei, bei mir im Wohngebiet die Fuß- und Radwege zu 
> erfassen bzw. Tags zu korrigieren.
>
> Ich dachte mir, ich fang mal mit ausgeschilderten Wegen an, z.B. 
> Zeichen 240 (s. Wiki 
> 
>  
> ).
> Wenn ich die Wege also mit /highway=path/, /bicycle=designated/, 
> /foot=designated/ und /segregated=no/ tagge, erhalte ich folgende 
> Ergebnisse:
> (...)



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

Re: [Talk-de] Brücken- und Tunnelnamen

[Stefan Dettenhofer (StefanDausR)]

Martin Koppenhoefer schrieb:
> naja, wie mans nimmt, m.E. waere das nicht widersinnig, ich wuerde den 
> Brueckennamen als Ausnahme sehen, den ich mit bridge:name=xz taggen 
> wuerde, der Strassenname gilt auf der Bruecke trotzdem und wird daher 
> als name=yz eingetragen.
>
Es gibt aber Brückenbezeichnungen (oder Straßenbezeichnungen), die viel 
bekannter sind, als der offizielle Straßenname.  In Regensburg weiß ich 
z.B. bei der "Osttangente" gar nicht, wie der offizielle Straßenname ist 
(wahrscheinlich auch noch "Walhalla-Allee"). Jeder sagt "Osttangente" 
obwohl die Bezeichnung im Straßenverzeichnis nicht vorkommt.
http://www.informationfreeway.org/?lat=49.01134893139958&lon=12.14300314090379&zoom=15&layers=0F0B0F
Ich denke das kommt schon auch darauf an, wie der Brückenname im 
täglichen Gebrauch benutzt wird.

Gibt es eigentlich Adressen auf Brücken? Wie lautet die dann 
(Brückenbezeichnung oder Straßenname)?

Gruß,
Stefan


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

Re: [Talk-de] Relation für Lange Ways

[Stefan Dettenhofer (StefanDausR)]

Hallo Jan,

ich würde für sinnvolle Abschnitte (z.B. eine Tagesetappe) jeweils eine 
Relation anlegen und die ganzen Relationen in einer "Super-Relation" 
zusammenfassen.
Ich hatte das mal hier
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz#Regionalwanderwege_.28RWW.29
mit dem "Jurasteig" so begonnen.

Gruß,
Stefan

Jan Tappenbeck schrieb:
> Moin !
>
> ich habe gestern gesehen, dass einige Fernwanderwege erst als eine 
> kleine Relation bestehen. Nun wollte ich nacheinander Lübeck ergänzen.
>
> Das würde ja zu Mega-Relationen führen die manchmal erst einige 100 
> Kilometer weiter fortgesetzt werden.
>
> Macht dass Sinn oder gibt es eine andere Möglichkeit zu arbeiten - 
> vielleicht mit Sub-Relationen ???
>
> Gruß Jan :-)
>
> ___
> 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 für Lange Ways

[Stefan Dettenhofer (StefanDausR)]

Ekkehart schrieb:
> Hi!
>
> Stefan Dettenhofer (StefanDausR) schrieb:
>   
>> ich würde für sinnvolle Abschnitte (z.B. eine Tagesetappe) jeweils eine 
>> Relation anlegen und die ganzen Relationen in einer "Super-Relation" 
>> zusammenfassen.
>> Ich hatte das mal hier
>> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz#Regionalwanderwege_.28RWW.29
>> mit dem "Jurasteig" so begonnen.
>> 
>
> (...)
>
> Außerdem: Woher soll jemand, der ebenso wie Du Wanderwege einträgt, 
> wissen daß da irgendwo noch eine weitere Relation rumeiert? Wenn er es 
> vermutet, wie soll er sie finden?
> (...)
>   
Daher habe ich die Super-Relation und Die einzel-Relationen ins Wiki 
geschrieben. Jeder der einen Wanderweg als (Super-)Relation definiert, 
sollte auch einen Eintag dazu im Wiki machen!

Kleinere Teilstücke sind einfach besser zu handhaben. und man kann ja 
(momentan zumindest noch) relevante Attribute redundant in alle 
Relationen aufnehmen. Fürs Rendern kann man dann die Superrelation 
vergessen.

Gruß,
Stefan



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

Re: [Talk-de] Fehler auf der Wiki-Seite der Wanderweg e für den Jurasteig

[Stefan Dettenhofer (StefanDausR)]

Hallo Jan,

danke für den Hinweis! Da hatte ich wohl beim Wiki-Kopieren einen Fehler 
gemacht. Ist nun berichtigt.

Stefan

Jan Tappenbeck schrieb:
> Moin !
> auf der Wanderwege-Seite 
> (http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Wanderwege-Netz)
>
> sind zwei Relationen für die einzelnen Abschnitte des Jurasteigs 
> (http://www.openstreetmap.org/browse/relation/49759) definiert.
>
> Etappe 2 und 3 haben nur dieselbe Relations-ID 
> (http://www.openstreetmap.org/browse/relation/37505)  - kann sich ein 
> ortskundiger der Sache einmal annehmen ?
>
> Gruß Jan :-)
>
> ___
> 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] Wieviel Plattenplatz brauchen die Tiles für Deutschland?

[Stefan Dettenhofer (StefanDausR)]

Hallo Michael,

die maxspeed-Karte http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte 
rechne ich auch mit Kosmos, allerdings erzeuge ich nur einen overlay und 
nicht die ganze Karte.
Da daher viele Kacheln leer bleiben (keine maxspeed-Info), kann ich 
diese nach dem Rendern löschen und spare so recht viel Platz. 
(Allerdings dauert das Löschen mit meiner Batch-Prozedur ähnlich lange 
wie das Rendern...)

Ich berechne einen Teilbereich von Mitteleuropa (E005 bis E017 und N35 
bis N55) und komme so auf folgende Werte: WErte in Klammern ist die 
Größe auf den Datenträger)
0 - 12: 58 MB (100 MB)
13: 68 MB (83 MB)
14: 293 MB (786 MB) (hier habe ich einige leere Dateien noch nicht gelöscht)
15-17 rechne ich erst gar nicht...

ein Rendern on demand ist mit Kosmos nicht so einfach möglich (da müsste 
ich mir erst mal was ausdenken).

Gruß,
Stefan


Michael Buchberger schrieb:
> Hallo Liste,
>
> bin gerade dabei mit Kosmos herumzuspielen und habe als Beispiel mal
> die kompletten Daten von Rheinland-Pfalz in den Zoomstufen 0-17
> berechnen lassen.
>
> Dabei werden 1779 Ordner mit 132 Dateien angelegt.
> Gesamtgröße ~3,6GB. Gebraucht hat mein Rechner dafür etwas
> über 24h
>
> Zoom 01,85kB
> Zoom 11,94kB
> Zoom 22,29kB
> Zoom 32,40kB
> Zoom 42,93kB
> Zoom 57,03kB
> Zoom 614,3kB
> Zoom 729,7kB
> Zoom 894,8kB
> Zoom 9293kB
> Zoom 101,45MB
> Zoom 114,08MB
> Zoom 1212,8MB
> Zoom 1335,6MB
> Zoom 1494,8MB
> Zoom 15265MB
> Zoom 16783MB
> Zoom 172450MB
>
> Das kommt mir jetzt ziemlich viel vor. Wieviele Terabytes verbraten den
> die Tiles von planet.osm
> in t...@h oder Mapnik?
>
> Tschuess
>  Michael
>   



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

Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?

[Stefan Dettenhofer (StefanDausR)]

Michael Buchberger schrieb:
> Hallo Stefan,
>   
>> die maxspeed-Karte http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte 
>> rechne ich auch mit Kosmos, allerdings erzeuge ich nur einen overlay und 
>> nicht die ganze Karte.
>> 
>
> Die Karte hatte ich auch noch im Hinterkopf. Muss mir unbedingt mal
> anschauen wie Du
> das mit den Openlayer-Overlays gemacht hast.
>
>   
Du musst halt in Kosmos einstellen, dass ein transparenter Hintergrund 
gerendert wird und dann die Tiles als overlay in OL einbinden.
>> Da daher viele Kacheln leer bleiben (keine maxspeed-Info), kann ich 
>> diese nach dem Rendern löschen und spare so recht viel Platz. 
>> (Allerdings dauert das Löschen mit meiner Batch-Prozedur ähnlich lange 
>> wie das Rendern...)
>>
>> 
>
> Über Dateigröße zu ermitteln?
>   
Ja ich mache das momentan mit einer DOS-BATCH-Datei:
for /R .\ %%N IN (*.PNG) DO if %%~zN LSS 1300 del %%N

Funktioniert, aber ist elend langsam (Vista?)

Gruß,
Stefan


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

Re: [Talk-de] Geschäft mit mehreren Funktionen

[Stefan Dettenhofer (StefanDausR)]

Martin Simon schrieb:
> 2009/1/21 Jan Tappenbeck :
>   
>> Moin !
>>
>> es gibt ein Tag für Cafe und Bäckerei.
>>
>> Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint.
>>
>> Gruß Jan :-)
>> 
>
> Dasselbe Problem begegnet einem auch bei anderen Konstellationen, z.B.
> Hotel/Kneipe/Restaurant oder Restaurant/Biergarten...
>
> Manche tragen das als getrennte nodes mit gleichem Namen ein, andere
> als amenity=bla;blubb
>
> Die erste Variante funktioniert halt für die
> Renderer/Konverter/POI-Suche, die zweite ist meiner Meinung nach
> eigentlich "richtiger", wird aber bis jetzt nicht ausgewertet...
>
>   
Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole 
übereinander/nebeneinander malen?
Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also 
statt

amenity=bla;blubb

dann gleich

amenity=bla_blubb

und dann rein passendes Symbol generieren.


Gruß,
Stefan




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

Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?

[Stefan Dettenhofer (StefanDausR)]

Michael Buchberger schrieb:
> Ich benutze auch Vista. Vielleicht mal ein kleines .net Progrämmchen
> schreiben
> das dies macht.
>   
Ich bin mehr der C/C++ Programmierer...
> Macht es Openlayers nix aus, wenn er zwischendurch keine Tiles findet, oder
> hast Du das abgefangen?
>   
OpenLayers ist das egal. Wenn, dann müsste man das wahrscheinlich auf 
Serverseite abfangen, aber bisher hat mich das noch nicht gestört.

Gruß,
Stefan


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