[Talk-de] OSM-Wochennotiz Nr.2
ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Hallo, Kolossos wrote: Hallo, weiß zufällig jemand, wie oft auf die Karte von openstreetmap.org im Monat zugegriffen wird oder kennt dazu eine Quelle? Ja, munin.openstreetmap.org! Da kannst Du immerhin rausfinden, wie viele Tiles abgerufen werden (so rund 1000 pro Sekunde im Schnitt glaub ich) und daraus Schluesse ziehen. Natuerlich braucht ein "Map View" immer ne ganze Menge Tiles. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landsat
Am 31.07.2010 21:31, schrieb Bodo Meissner: > -Original Message- > From: talk-de-boun...@openstreetmap.org [mailto:talk-de- > boun...@openstreetmap.org] On Behalf Of Bodo Meissner > Sent: Saturday, July 31, 2010 9:31 PM > To: talk-de@openstreetmap.org > Subject: Re: [Talk-de] Landsat > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 31.07.2010 14:13, schrieb Rolf Meyerhof: > > > Wo ist die Verbindung von Josm zu Landsat geblieben.?? > > Hallo Rolf, > > was meinst Du mit der Frage? > Werden keine Bilder mehr angezeigt (stattdessen vielleicht eine Exception) > oder weißt Du nicht, wie man dem WMS-Plugin den Zugriff auf Landsat > beibringt? > > Bei mir funktioniert derzeit der Landsat-WMS-Server nicht: >Grabbing WMS > http://onearth.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&st > yles=&format=image/jpeg&bbox=12.7956371,49.324,12.8229199,49.3733202&s > rs=EPSG:4326&width=500&height=499 >java.net.SocketTimeoutException: Read timed out > > Es gab auch früher schon Zeiten, in denen der Server nicht ging. (siehe > auch http://onearth.jpl.nasa.gov/) > > > Bodo > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkxUdx8ACgkQnMz9fgzDSqee6wCcCDRtxTGe1POhnJFwWNMAXogO > R9sAn3Ua6TCvWWA4a3dQjIjQSAfu3HQv > =vekY > -END PGP SIGNATURE- > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > Hallo Bodo Landsat ist bei mir seit einigen Tagen weg. Ich hatte gehofft dass es sich wieder gibt. Es gibt aber mails auf osm-Talk die leider nicht richtig deuten kann. Siehe diese mail. yeah, I'm having the same issues (Read timed out) Roman > From: Tomas Straupis > Subject: [OSM-talk] Landsat? > Hello > Is anybody else experiencing landsat problems in JOSM? > For about three days now landsat images are not available to JOSM. > http://onearth.jpl.nasa.gov/ says something about evil ?repetitive > requests for non-cached, small WMS tiles?. Does that mean no more > landsat in JOSM? Mit freundlichen Grüßen Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 Und bitte Abfilterung von Beiträgen mit >70% Quoteanteil. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Zugriffszahlen auf openstreetmap.org
Hallo, weiß zufällig jemand, wie oft auf die Karte von openstreetmap.org im Monat zugegriffen wird oder kennt dazu eine Quelle? Die Größenordnung wäre halt eben mal interessant und ob eine Million Besucher mehr oder weniger stark ins Gewicht fallen. Grüße Kolossos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
>Ich wuerde mir automatischen Plaintext wuenschen. +1 Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am Samstag 31 Juli 2010, 22:43:57 schrieb Jonas Stein: > Da ich gerade mal wieder Beschwerden ueber html-Mails in dieser > Liste las, folgende Ueberlegung: > > In dieser Mailingliste tauchen immer wieder Mails > > mit html Inhalt und/oder > html-attachment > > auf. Diese Nachrichten werden typischerweise schnell > unlesbar. > > Das hat teils technische Gruende (Mailclients, Newsreader, > Mail-News-Gateway) teils liegt es am Anwender, das zu diskutieren > eruebrigt sich. > Die meisten schicken standardkonform auch eine Plaintextvariante mit, wenn sie HTML versenden, leider nicht alle. Abgesehen davon laesst sich jeder mir bekannte Mailer auf Plaintext umstellen. > Als einfache Abhilfe kann der Verwalter in (allen gaengigen) Mailinglisten > einstellen, dass der html-Teil automatisch nach reinen Text gewandelt wird. > wenn das geht, auch ok. Notfalls kein HTML erlauben, das geht auf jeden Fall. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Hallo,
Tirkon wrote:
Für OSM müsste jetzt für jede mögliche Kombination von Nachbarn die
gemeinsame Grenzlinie ermittelt werden und in einen Weg umgewandelt
werden, der dann mit boundary = administrative und admin_level=9
getaggt wird.
Das kann man in der PostGIS machen (also Shapefiles in PostGIS einlesen,
dort dann rechnen lassen).
Ich habe das vor einiger Zeit mal fuer Dresden gemacht und
stichwortartig dokumentiert, was zu tun ist, und haenge das unten an.
Bye
Frederik
Shapefile mit shp2pgsql in Postgis einlesen (in eine neue Tabelle
"dresden") [anmerkung: in den shapes, um die es hier ging, gab es eine
spalte namens "sicad_txt", in der eine Zahl stand, die das Gebiet
eindeutig beschrieb)
CREATE TABLE multilinestrings (
id SERIAL NOT NULL UNIQUE,
gid1 INTEGER NOT NULL,
gid2 INTEGER NOT NULL
);
SELECT AddGeometryColumn('multilinestrings', 'geom', 4326,
'MULTILINESTRING', 2);
INSERT INTO multilinestrings (gid1, gid2, geom) SELECT
int4(a.sicad_txt), int4(b.sicad_txt),
ST_Multi(ST_Intersection(a.the_geom, b.the_geom)) FROM dresden a,
dresden b WHERE a.sicad_txtb.the_geom);
Jetzt hat man die Linien, wo sich einzelne Stadtteile beruehren. Die
Aussengrenze fehlt noch, dazu hab ich vermutlich etwas un-elegant:
create table outline (id serial not null unique);
SELECT AddGeometryColumn('outline','geom',4326,'MULTILINESTRING',2);
insert into outline (id,geom) values(0, (select
ST_Boundary(ST_Multi(ST_Union(the_geom))) as geom from dresden));
insert into multilinestrings(gid1,gid2,geom) select
int4(a.sicad_txt),0,ST_Multi(ST_Intersection(a.the_geom, b.geom)) FROM
dresden a, outline b where ST_Touches(a.the_geom,b.geom);
Und um die resultierenden multilinestrings zu zerlegen
CREATE TABLE ways (
id serial not null,
gid1 INTEGER NOT NULL,
gid2 INTEGER NOT NULL
);
SELECT AddGeometryColumn('ways', 'geom', 4326, 'LINESTRING', 2);
INSERT INTO ways (geom, gid1, gid2) SELECT
(ST_Dump(ST_LineMerge(geom))).geom, gid1, gid2 FROM multilinestrings;
Nun hat man alle Grenz-Ways als einzelne Geometrien in der Datenbank und
kann mittels einem modifizierten shp2osm-Skript diese Ways in
.osm-Dateien verwandeln und die passenden Relationen anlegen. Dazu habe
ich ein Skript, das ist aber eine ziemliche Perl-Bastelwueste. Kann
gern jeder haben, aber man muss sich schon mit Perl auskennen.
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Da ich gerade mal wieder Beschwerden ueber html-Mails in dieser Liste las, folgende Ueberlegung: In dieser Mailingliste tauchen immer wieder Mails mit html Inhalt und/oder html-attachment auf. Diese Nachrichten werden typischerweise schnell unlesbar. Das hat teils technische Gruende (Mailclients, Newsreader, Mail-News-Gateway) teils liegt es am Anwender, das zu diskutieren eruebrigt sich. Als einfache Abhilfe kann der Verwalter in (allen gaengigen) Mailinglisten einstellen, dass der html-Teil automatisch nach reinen Text gewandelt wird. Ich wuerde mir automatischen Plaintext wuenschen. Was meint ihr dazu? Beste Gruesse, -- Jonas Stein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Am 28.07.2010 11:05, schrieb Tirkon: Moin, eine der wenigen Dinge, die wir nicht mappen können, sind Grenzen. Dazu sind wir auf Hilfe von Außen angewiesen. Für das nordwestliche Niedersachsen liegen die amtlichen Grenzen aller Kommunen und deren Ortsteile in Form der sogenannten Gemarkungen mit einer Genauigkeit von 5 Metern vor. Sven Geggus hat das amtsübliche Shapeformat inzwischen in das *.osm Format umgesetzt. Soweit sich das mit der OSM-typischen GPS-Genauigkeit überprüfen lässt, ist diese Umsetzung hochgenau gelungen. Dafür erst einmal einen recht herzlichen Dank an Sven. Die Shape Dateien haben aber von OSM abweichende Datenstruktur, welche sich in der *.osm Datein darstellt, wie folgt: Jede Gemarkung besteht aus einem rechts umlaufenden geschlossenem Weg (Polygon), welcher mit dem Namen und weiteren Eigenschaften der Gemarkung getaggt ist. Dadurch stoßen an den Grenzen zweier benachbarter Gemarkungen zwei gegenläufige Wege aufeinander, wodurch dann auch doppelte Nodes entstehen. Die doppelten Nodes lassen sich mit der Reparaturfunktion von JOSM entfernen, so dass die gegenläufigen Wege nun dieselben nodes benutzen. Nur an den Außengrenzen des Importes als auch bei den Nordseeinseln sind dann einfache Wege vorhanden, da es dort keine Nachbarn gibt. Für OSM müsste jetzt für jede mögliche Kombination von Nachbarn die gemeinsame Grenzlinie ermittelt werden und in einen Weg umgewandelt werden, der dann mit boundary = administrative und admin_level=9 getaggt wird. Damit wäre schon viel erreicht. Wenn dann noch zusätzlich entsprechend des ursprünglichen Polygons der Gemarkung auf diesen Wegen eine Gemarkungs-Relation errichtet werden könnte mit type = multipolygon admin_level = 9 boundary = administrative de:amtlicher_gemeindeschluessel = x name = Name der Gemarkung oder x sowie den Tags der Gemarkung, wäre das noch die Krönung. Alternativ kann dieser letzte Punkt auch in Handarbeit ausgeführt werden. Aus diesem Konstukt kann ich dann mit Ortskenntnissen und in Handarbeit die Ortsteile-, Kommunen- und Landkreisgrenzen sowie die Außengrenze des Importes in die niedersächsische Außengrenze und die Grenzen der Anrainer des Importgebietes einbauen. Viele Gemarkungen sind heute keine administrative Einheit mehr. Von daher muss dort der admin_level entfernt werden. Von daher macht also ein Upload auch nach solch einer Umsetzung keinen Sinn. deutsche Grenzen im OSM Wiki: http://wiki.openstreetmap.org/wiki/DE:Grenze Im Vergleich mit früheren Grenzinporten (Dresden) zeigt sich, dass dieses Problem bei solchen amtlichen Importen aus Shapedateien immer wieder auftritt. Ein Programm oder Script könnte also zusammen mit dem Verfahren von Sven auch später diesen Dienst leisten. Wenn ich als Laie Sven richtig verstanden habe, wäre dies gleichzeitig ein erster Weg, um für die vorhanden Formatwandlungsprogramme im Geobereich einen OSM Ausgang bzw einen shp2osm Konverter zu bekommen. Über dieses Thema hat er ausführlich auf der letzten Fossgis 2010 referiert: http://www.fossgis.de/konferenz/2010/attachments/71_osm-datenaufbereitung-fossgis-2010.pdf Bitte habt Verständnis dafür, dass ich die unfertige *.osm Datei nicht streuen möchte. Bei früheren Importen wurden diese mehrfach in diversen unfertigen Formen hochgeladen und musste dann - teilweise in mühevoller Handarbeit - von Frederik wieder entfernt werden. Wenn jemand diese Aufgabe angehen möchte, sende ich die Datei daher privat zu. shape-dateien konnte doch tobias.wendorff ins osm-format konvertieren. reicht das nicht ! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 27.07.2010 17:56, schrieb steffterra: > > Am 27.07.2010 um 15:09 schrieb Tobias Knerr: >> Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell >> * eine Fahrtrichtung >> oder >> * eine Fahrspur bzw. Gruppe von Fahrspuren > > Das Modell kann beides. Diese Eigenschaft macht es m.E. etwas verwirrend. "Ein zusätzlicher Way repräsentiert eine Fahrspur" wäre beispielsweise deutlich einfacher zu erklären (und im Editor darzustellen) als ein "kommt darauf an". Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die Einführung eines Linienbündel-Modells ist. ;) Aber ich wollte ja eigentlich auf einige Detailfragen zu deinem Modell zu sprechen kommen. Ich habe im Folgenden mal diejenigen Beispiele herausgegriffen, bei denen eine leichte Änderung am Szenario besser klar macht, worauf ich hinaus will. > Beispiel 1: in der "Wirklichkeit" sieht unsere Beispielstraße so aus: ganz > normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne > Unterschiede, egal aus welcher Richtung man kommt. > Geschwindigkeitsbegrenzung: 50km/h. > [...] > Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von > 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. > Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden > Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische > Verbindugnsstraße wird. Die Süd->Nord-Richtung führt nach Hamburg, die > Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein > Beispiel ;-) > [...] > -way (Nord->Süd): maxspeed=60, destination=München > -daten-way: highway=secondary, name=Beispielstraße > -way (Süd-Nord): maxspeed=50, destination=Hamburg Beispiel 2a: Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also einspurig. Wird das dennoch mit zwei Zusatzways dargestellt? > Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung > Norden->Süden erweitert, auf der anderen Seite jedoch nicht > [...] > Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der > Richtung Nord->Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg > verpasst, weil diese Straßenseite so gefährlich wurde. > [...] > -> in meinem Modell: > > -way (außen eingezeichnet Nord->Süd): maxspeed=60, destination=München, > cycleway=lane, bicycle=designated > -way (innen eingezeichnet Nord->Süd): maxspeed=60, destination=München > -daten-way: highway=secondary, name=Beispielstraße > -way (Süd->Nord): maxspeed=50 Beispiel 4a: Nehmen wir weiter an, die äußere Fahrspur Nord->Süd ist 3m breit, der Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per surface/smoothness-Tags beschreiben. Wie werden diese diese Informationen ergänzt? Beispiel 4b: Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der Fahrbahn. Wie sieht die entsprechende Ergänzung aus? Beispiel 4c: Anders als bei 4b ist der Radweg jetzt zwischen der Fahrbahn und dem Parkstreifen. Wie unterscheidet sich dieser Fall vom Tagging zu 4b? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 21:14:54 schrieb steffterra: > Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den > way, den es betrifft hätte man es einfach visualisert, an welchem way man > soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich > finde. forward/backward/left/right könnte der intelligente Editor so > wirklich automatisch vergeben. > eben :-) > Gut, also keine Gruppierung mehr nötig? Hätte ich kein Problem, mit wenn > man das vermeiden könnte. > auf Datenebene ist das schon noetig, wie soll der Editor sonst wissen, was zusammengehoert? > Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind > doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung > keine Entwickler nötig wären... ;-) > Beim Konzept kann ich durchaus behilflich sein, aber von Java und Flash halt ich mich fern. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 21:10:38 schrieb steffterra: > Wenn Du mein Eingangsposting noch einmal in Ruhe liest, wird Dir auffallen, > dass Radwege, etc. keine eigenen ways bekommen. sie werden einfach am > richtigen Richtigungsway getaggt. verstehe... > Das ist einer der Unterscheide zum > Linienbündel, das alles aufgedröselt hat. Ich möchte _nur_ die > richtugnsabhängigen Tags in eigene ways packen und Fahrspuren auch _nicht > generell_ sondern nur da, wo es der Plausibilität und besseren Abbildung > der Wirklichkeit _nötig_ ist. > d.h. also die von mir beschriebene Situation kann durchaus vorkommen. > >> Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet > >> es entsprechend. > > eben, deshalb halte ich das Radwegtagging am auf der Seite des > entsprechenden Richtungsway völlig ausreichend. In einem anderen Posting > (es dürften 8-10 Postings/Mails vor diesem gewesen sein, schau mal ein > wenig durch) habe ich 5 Beispiele verglichen, wie es nach dem jetzigen > System und wie nach meinem Modell getaggt würde. Da siehst du den Radweg > und andere Dinge entsprechend im Vergleich getaggt. > > >>> Es sind halt zwei verschiedene Ansaetze. > >>> Du haengst dich zu sehr an der Richtung auf. Ich versuche > >>> normalerweise erst > >>> mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich > >>> alles neu > >>> schreibe. > >> > >> Ich hänge mich nicht zu sehr an der Richtung auf, > > > > dafuer erwaehnst du das Thema zu oft ;-) > > Es _ist_ das Thema ;-) Siehe Betreff. > lassen wir diese Diskussion, bringt ja eh nix ;-) > >> Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die > >> Spezialfälle der Gruppierung mittels Relationen darstellst. Also die > >> Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die > >> Gruppierung ncihts anderes als eine Relation wäre. > > > > im Sinne von "zusammenfassen von Objekten", also in diesem Falle der > > Ways. Konkret: "Relation XY sagt aus, dass Way 12, Way 34 und Way 56 > > zusammengehoeren und eine 'Gruppe' bilden". > > Verstaendnisproblem. > > Müsste sie auch noch aussagen, welcher way welche Rolle hat, oder ergibt > sich das aus dem tagging? > Waere wahrscheinlich sinnvoll, wenn man diesen Weg geht. > Dann könnte man auch sehr einfach eine Brücke in einer Relation > zusammenfassen, schließlich ist das ja auch eine Fahrbahn mit > unterscheidlichen Elementen. Hmm das ist eine interessante Geschichte. > Denn sobald man richtugnsways, datenway, tram und anderes mit auf einer > Brücke hat müsste man zunächst die Fahrbahnen ohne Tram zu einer Gruppe > zusammenfassen und dann diese Gruppe und die Tram-Line in eine Relation > für die Brücke zusammenfassen. z.B. > Da bin ich aber eher dagegen, da es das > unnötig verkomplizieren würde. Trams sind oft Fahrbahnbegleitend oder > sogar gemeinschaftlich mit einer Fahrspur genutzt. Aus diesem Grund würde > ich eine tram-line wie eine Fahrspur in die Gruppe mit aufnehmen. ja. > Man kann > sie ja auch nciht an einem highway drantaggen, da sie einen eigenen way > besitzen muss. warum? grade wenn das Gleis auf der Fahrbahn verlaeuft, gibt es dafuer keinen Grund. > Also gerne entweder mit gemeinsamen Knoten einer Fahrspur > (wenn sie in der Fahrspur eingelassen ist) ist nein. > oder bei baulicher Trennung > eben normal neben den highway-spuren. > ja. > Sorry für den kleinen Abstecher, aber damit haben wir auch den Spezialfall > mit aufgenommen und sogar die Brücke mit reingebracht, die auch wunderbar > vom Renderer genutzt werden könnte, dass man nicht immer diese > "durchsichten" Brücken hat, wenn sie in einer Brückenrelation erfasst > wurden. Diese Brückenrelation ersetzt dann die vorher und danach > bestehende Gruppierungs-Relation, falls dort sonst richtungsabhängie Tags > nötig wären. (sonst ist ja eine Gruppierung auch nicht nötig) > eins nach dem anderen, das klingt mir schon wieder viel zu kompliziert ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landsat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 31.07.2010 14:13, schrieb Rolf Meyerhof: > Wo ist die Verbindung von Josm zu Landsat geblieben.?? Hallo Rolf, was meinst Du mit der Frage? Werden keine Bilder mehr angezeigt (stattdessen vielleicht eine Exception) oder weißt Du nicht, wie man dem WMS-Plugin den Zugriff auf Landsat beibringt? Bei mir funktioniert derzeit der Landsat-WMS-Server nicht: Grabbing WMS http://onearth.jpl.nasa.gov/wms.cgi?request=GetMap&layers=global_mosaic&styles=&format=image/jpeg&bbox=12.7956371,49.324,12.8229199,49.3733202&srs=EPSG:4326&width=500&height=499 java.net.SocketTimeoutException: Read timed out Es gab auch früher schon Zeiten, in denen der Server nicht ging. (siehe auch http://onearth.jpl.nasa.gov/) Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxUdx8ACgkQnMz9fgzDSqee6wCcCDRtxTGe1POhnJFwWNMAXogO R9sAn3Ua6TCvWWA4a3dQjIjQSAfu3HQv =vekY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:59 schrieb Guenther Meyer: > Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: >>> der Editor kennt die Referenzrichtung des Weges, und kann sein >>> backward Tag >>> danach ausrichten und entsprechend anzeigen. >>> Wie das in der Realitaet aussieht, weiss sowieso nur der User. >> >> Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da >> kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und >> wie das dann vom Editor interpretiert wird, um daraus den richtigen >> backward/forward/left/right-tag zu machen. >> > > durch grafische Eingabe!? > > Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils > oder > einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite > die Eigenschaft gueltig ist. > > Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr > an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Gut, also keine Gruppierung mehr nötig? Hätte ich kein Problem, mit wenn man das vermeiden könnte. Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:53 schrieb Guenther Meyer: > Am Samstag 31 Juli 2010, 09:25:54 schrieb steffterra: >> Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da >> dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar >> nicht gerendert, da der highway-tag fehlt. > > wenn ich dich richtig verstehe, koennen die zusaetzlichen ways u.a. auch Rad- > und Fussgaengerwege sein, getrennte Ein/Ausfaedel- und Abbiegespuren sind > genau so moeglich. > Bisher werden diese ueber ein Highway-Tag gekennzeichnet, willst du dieses > auch verwerfen und was neues einfuehren? Wenn Du mein Eingangsposting noch einmal in Ruhe liest, wird Dir auffallen, dass Radwege, etc. keine eigenen ways bekommen. sie werden einfach am richtigen Richtigungsway getaggt. Das ist einer der Unterscheide zum Linienbündel, das alles aufgedröselt hat. Ich möchte _nur_ die richtugnsabhängigen Tags in eigene ways packen und Fahrspuren auch _nicht generell_ sondern nur da, wo es der Plausibilität und besseren Abbildung der Wirklichkeit _nötig_ ist. >> Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet >> es entsprechend. eben, deshalb halte ich das Radwegtagging am auf der Seite des entsprechenden Richtungsway völlig ausreichend. In einem anderen Posting (es dürften 8-10 Postings/Mails vor diesem gewesen sein, schau mal ein wenig durch) habe ich 5 Beispiele verglichen, wie es nach dem jetzigen System und wie nach meinem Modell getaggt würde. Da siehst du den Radweg und andere Dinge entsprechend im Vergleich getaggt. >>> Es sind halt zwei verschiedene Ansaetze. >>> Du haengst dich zu sehr an der Richtung auf. Ich versuche >>> normalerweise erst >>> mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich >>> alles neu >>> schreibe. >> >> Ich hänge mich nicht zu sehr an der Richtung auf, > > dafuer erwaehnst du das Thema zu oft ;-) Es _ist_ das Thema ;-) Siehe Betreff. >> sondern ich versuche >> mit meinem Modell das Problem mit der Richtung zu beheben. > das sei dir ja gegoennt. Alles weitere dazu hatte ich bereits geschrieben. Das war nur die Antwort darauf, warum ich es von richtungsabhängigen Tag abhängig mache. Es ist das Thema, es ist der Hauptgrund (mit allen positiven Nebeneffekten die ich gerne mitnehmen), dass ich mir das Modell überhaupt überlegt habe. Also ist klar, dass ich darauf auch besonders eingehe, oder? Dass ich deshalb die Nebeneffekte (positive und negative gleichermaßen) deshalb noch lange nicht ausser Acht lasse, kann man in meinen Mails dieses Threads nachlesen. > > Irgendwie musst du die Gruppierung ja in der Datenbank speichern. > Das naheliegendste ist da natuerlich eine einfache Relation. > Eine andere Moeglichkeit waere, die Information an den mittleren > Weg zu > taggen (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? >>> >>> Das hat nichts miteinander zu tun. >>> Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. >>> Wie du die nutzt, steht dir im Prinzip total frei. >>> Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. >>> ID. >> >> Ja eben, wie errechnet sich denn die ID einer Relation? >> > > keine Ahnung. Ich wuerde vermuten, dass die erst von der API beim comitten > vergeben wird. Der lokale Editor kann ja nicht wissen, welche IDs frei sind. > > >> Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle >> _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo >> nötig/ >> sinnvoll), die dieses Model bietet. > > wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? >>> >>> Ich glaube, da liegt ein Verstaendnisproblem vor: >>> Das einzige, wozu ich eine Relation benutzt haette, waere die >>> Abbildung des >>> Objekts "Gruppe" selbst. >> >> Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die >> Spezialfälle der Gruppierung mittels Relationen darstellst. Also die >> Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die >> Gruppierung ncihts anderes als eine Relation wäre. >> > > im Sinne von "zusammenfassen von Objekten", also in diesem Falle der Ways. > Konkret: "Relation XY sagt aus, dass Way 12, Way 34 und Way 56 > zusammengehoeren und eine 'Gruppe' bilden". > Verstaendnisproblem. Müsste sie auch noch aussagen, welcher way welche Rolle hat, oder ergibt sich das aus dem tagging? Dann könnte man auch sehr einfach eine Brücke in einer Relation zusammenfassen, schließlich ist das ja auch eine Fahrbahn mit unterscheidlichen Elementen. Hmm das ist eine interessante Geschichte. Denn sobald man richtugnsways, datenway, tram und anderes mit auf einer Brücke hat müsste man zunächst die Fahrbahnen ohne Tram zu einer Gruppe zusammenfassen und dann diese Gruppe
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Tirkon glaubte zu wissen: > Moin, > > eine der wenigen Dinge, die wir nicht mappen können, sind Grenzen. > Dazu sind wir auf Hilfe von Außen angewiesen. Für das nordwestliche > Niedersachsen liegen die amtlichen Grenzen aller Kommunen und deren > Ortsteile in Form der sogenannten Gemarkungen mit einer Genauigkeit > von 5 Metern vor. Sven Geggus hat das amtsübliche Shapeformat > inzwischen in das *.osm Format umgesetzt. Soweit sich das mit der > OSM-typischen GPS-Genauigkeit überprüfen lässt, ist diese Umsetzung > hochgenau gelungen. Dafür erst einmal einen recht herzlichen Dank an > Sven. [...] > type = multipolygon > admin_level = 9 > boundary = administrative > de:amtlicher_gemeindeschluessel = x Ist die Gemeinde nicht admin_level=8 und die einzelnen Teilorte admin_level=9 ? flo -- > *PLONK* Du willst mit |X-Newsreader: Microsoft Outlook Express 5.00.2615.200 plonken? LOL [Ulf Müller zu Robert Piek in dciwb] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 31.07.2010 14:40, schrieb Heiko Jacobs: > Jan Tappenbeck schrieb: >> Wenn ich jetzt im Wiki bei landuse = meadow [1] nachlese dann steht >> da Wiese ohne Gehölzer > > ... aber so (Wiese) auch nur in der deutschen Version > >> Wenn ich mir nun aber den Eintrag für landuse = farmland ansehe sind >> auf den Bild mehrere Gründlandflächen abgebildet und nicht als >> landuse = meadow [3] bezeichnet. Hier wird dann wieder von Weiden >> gesprochen. > > Und Obstplantagen sind auch dabei, für die es auch orchard gibt > farmland scheint generell "Ackerbau und Viehzucht" ohne Unterscheidung > zu sein? ... was man alternativ auch detaillierter taggen könnte, > wenn man wollte (orchard, meadow, ... gibt's noch mehr? Ich meine, > mir wäre auch mal mehr Detaillierung untergekommen ...) Eine Unterscheidung zwischen Grünfläche (Wiese,Weide) und Ackerfläche fände ich wichtig. Diese Arten sind zumindest ganzjährig zu unterscheiden. Unterschiedliche Tags für Wiesen und Weiden finde ich etwas problematisch: * von außen kann dies (zumindest in meiner Gegend) nicht immer unterschieden werden, wenn charakteristische Merkmale (Zaun, frisch gemäht) fehlen. Es geht also nur mit lokaler Kenntnis. * die Nutzung kann durchaus wechseln (auch innerhalb eines Jahres) * wenig bewandte Anwender sehen da nur Grünflächen Gerne kann man das taggen. Die fehlerfreie Anwendung wird aber wohl auf einen kleine Nutzerkreis beschränkt sein. Beste Grüße, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMVCIAAAoJEPT/XJzV1tNzu5kH/AiLwoXHy6ARq9/mgkIwDA3O oR4RFE5bypXqyiRZOVK13NakZT3WHvJv9HvF8F1klSIZXmnqHPRPGIZICSKAQurR AzEno8UJCor4bEh2is/5Ss89z9Y8zcg5V1Meba7EEPM8QZVV2uJWHOpjXW3zV3Gd iESo9RrahzZf6TfARCC+PUOVlgxEDx0UciXZHrUU9vmXhjcSPSUwtWyc5I895isn ivqMe3Y99j0jWPrtVIK7TXYpKCextl2qIg7QTTCzO4yYf9Qm5S/Sc903DBX6/eK7 AgX4ElCYdrT9d6GZ8sl2gpDp9pv/qHwswJmLSMZr4+eWVyS5wrHJrVjx8jh3sL8= =NIex -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?
hike39 glaubte zu wissen: > Am 28.07.2010 03:39, schrieb Florian Gross: >> Johann H. Addicks glaubte zu wissen: >>> Hallo, entsinne mich, dass das Plugin "Piclayer" früher einmal eine >>> Funktion hatte, um geladene Bilder nicht nur zu zoomen und zu drehen, >>> sondern auch zu verschieben (Icon mit blauen Cursorpfeilen), siehe auch >>> Bebilderung unter >>> http://wiki.openstreetmap.org/wiki/DE:Piclayer/Anleitung >>> Aktuell vermisse ich diese Funktion jedoch. >>> Wo kann die sich versteckt haben? Oder habe ich meinen Josm vergurkt? >> >> Schau mal hier: http://omploader.org/vNTJlYQ/Bildschirmfoto-21.png >> >> Bei mir ist es die rote Fahne mit der weißen Hand. > > Wie bist Du an diesen Button gekommen? Das ist doch kein Bestandteil von > PicLayer. Ich arbeite schon länger sehr intensiv mit diesem Tool, aber > dieses ist mir noch nicht aufgefallen. Frag JOSM. Das zeigt mir das so an. Ich hab nur das plugin installiert, mehr nicht. Aber ich hatte vorher mal ein anderes Symbol, das IMO aussagekröftiger war. flo -- Raubkopien sind wie Kinderüberraschungen: Spiel (Games), Spaß (Apps) und Überraschung (Polizei) [Evrim Sen im wer-weiss-was- Experten-Chat] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
Jan Tappenbeck schrieb: Wenn ich jetzt im Wiki bei landuse = meadow [1] nachlese dann steht da Wiese ohne Gehölzer ... aber so (Wiese) auch nur in der deutschen Version Wenn ich mir nun aber den Eintrag für landuse = farmland ansehe sind auf den Bild mehrere Gründlandflächen abgebildet und nicht als landuse = meadow [3] bezeichnet. Hier wird dann wieder von Weiden gesprochen. Und Obstplantagen sind auch dabei, für die es auch orchard gibt farmland scheint generell "Ackerbau und Viehzucht" ohne Unterscheidung zu sein? ... was man alternativ auch detaillierter taggen könnte, wenn man wollte (orchard, meadow, ... gibt's noch mehr? Ich meine, mir wäre auch mal mehr Detaillierung untergekommen ...) Ist die Wiese vielleicht nur zur Heugewinnung und es dürfen keine Kühe & Co dort laufen oder wie ist das zu verstehen. So ist's definiert. Wiese = Heu Weide = Tiere stehen drumrum mit Zaun drumrum (Schafweide samt Wanderschäfer ohne Zaun vernachlässigen wir mal ...) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landsat
Hallo, Wo ist die Verbindung von Josm zu Landsat geblieben.?? .mfg Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: > > der Editor kennt die Referenzrichtung des Weges, und kann sein > > backward Tag > > danach ausrichten und entsprechend anzeigen. > > Wie das in der Realitaet aussieht, weiss sowieso nur der User. > > Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da > kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und > wie das dann vom Editor interpretiert wird, um daraus den richtigen > backward/forward/left/right-tag zu machen. > durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
OT: geht's bitte auch ohne HTML? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Samstag 31 Juli 2010, 09:25:54 schrieb steffterra: > Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da > dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar > nicht gerendert, da der highway-tag fehlt. wenn ich dich richtig verstehe, koennen die zusaetzlichen ways u.a. auch Rad- und Fussgaengerwege sein, getrennte Ein/Ausfaedel- und Abbiegespuren sind genau so moeglich. Bisher werden diese ueber ein Highway-Tag gekennzeichnet, willst du dieses auch verwerfen und was neues einfuehren? > Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet > es entsprechend. > klar. > > Es sind halt zwei verschiedene Ansaetze. > > Du haengst dich zu sehr an der Richtung auf. Ich versuche > > normalerweise erst > > mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich > > alles neu > > schreibe. > > Ich hänge mich nicht zu sehr an der Richtung auf, dafuer erwaehnst du das Thema zu oft ;-) > sondern ich versuche > mit meinem Modell das Problem mit der Richtung zu beheben. > das sei dir ja gegoennt. Alles weitere dazu hatte ich bereits geschrieben. > >>> Irgendwie musst du die Gruppierung ja in der Datenbank speichern. > >>> Das naheliegendste ist da natuerlich eine einfache Relation. > >>> Eine andere Moeglichkeit waere, die Information an den mittleren > >>> Weg zu > >>> taggen (wahrscheinlich sogar die bessere). > >> > >> ich dachte an eine ID die durch einen einfachen Algorithmus aus den > >> beteiligten ways automatisch errechnet wird. Ist das bei Relationen > >> genauso? > > > > Das hat nichts miteinander zu tun. > > Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. > > Wie du die nutzt, steht dir im Prinzip total frei. > > Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. > > ID. > > Ja eben, wie errechnet sich denn die ID einer Relation? > keine Ahnung. Ich wuerde vermuten, dass die erst von der API beim comitten vergeben wird. Der lokale Editor kann ja nicht wissen, welche IDs frei sind. > Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle > _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo > nötig/ > sinnvoll), die dieses Model bietet. > >>> > >>> wie jetzt, dein Modell? > >> > >> Ja meines. Wie wäre mein Modell mit Relationen für alle > >> angesprochenen > >> Spezialfälle umsetzbar? > > > > Ich glaube, da liegt ein Verstaendnisproblem vor: > > Das einzige, wozu ich eine Relation benutzt haette, waere die > > Abbildung des > > Objekts "Gruppe" selbst. > > Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die > Spezialfälle der Gruppierung mittels Relationen darstellst. Also die > Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die > Gruppierung ncihts anderes als eine Relation wäre. > im Sinne von "zusammenfassen von Objekten", also in diesem Falle der Ways. Konkret: "Relation XY sagt aus, dass Way 12, Way 34 und Way 56 zusammengehoeren und eine 'Gruppe' bilden". Verstaendnisproblem. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
moin, Am 31.07.2010 13:28, schrieb Jan Tappenbeck: Ist die Wiese vielleicht nur zur Heugewinnung und es dürfen keine Kühe & Co dort laufen oder wie ist das zu verstehen. richtig, eine Wiese wird gemäht (heute wohl mehr zur Silagegewinnung), eine Weide wird vom Vieh beweidet. VG Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiese gleich / ungleich Weide ??
Hi ! in der letzten Zeit habe ich mich ausgiebig mit der Erfassung von Landuse beschäftigt. Dabei ist mir aufgefallen das viele Grünflächen (schreibe bewußt nicht Weide oder Wiese) mit landuse = farmland definiert haben. Wenn ich jetzt im Wiki bei landuse = meadow [1] nachlese dann steht da Wiese ohne Gehölzer - mit wäre danach landuse = scrub was viele z.b. im Bereich von Autobahnauffahren verwenden. Wenn ich mir nun aber den Eintrag für landuse = farmland ansehe sind auf den Bild mehrere Gründlandflächen abgebildet und nicht als landuse = meadow [3] bezeichnet. Hier wird dann wieder von Weiden gesprochen. Ist die Wiese vielleicht nur zur Heugewinnung und es dürfen keine Kühe & Co dort laufen oder wie ist das zu verstehen. Wer kann mich aufklären. Meine Auffassung ist nämlich arbeitsintensiver als die allgemeine landuse = farmland-Definition. Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dmeadow [2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub [3] http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dfarm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=village area Quelle
Hierzu ein paar Links: http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Grenzen http://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen -- View this message in context: http://gis.638310.n2.nabble.com/place-village-area-Quelle-tp5357667p5357941.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:27 schrieb Guenther Meyer: Für die Umsetzung müssen natürlich alle an einem Strang ziehen. +1 Abwärtskompatibilität bleibt ja dennoch erhalten. lassen wir uns ueberraschen. ich denke das koennte bei deinem Modell interessant werden. Man muesste mal ausprobieren, was ein heutiger Renderer aus deinem Modell machen wuerde (kann ich gerne machen, sobald was getaggtes vorliegt)... Das wäre cool. Leider habe ich dazu jetzt in der anderen mail geantwortet... :-/ wie das gerendert würde. Aber visualisiert ist es natürlich noch einfacher zu verstehen. Besonders der Richtugnsway, der nach meinem Modell keinen eigenen highway-tag hat, sollte eigentlich nicht gerendert werden, der datenway schon. Da die richtungsabhängigen Tags dann auf den ways liegen wird man diese Trennung auch bei der Software berücksichtigen müssen. Doch da helfen nur note-tags, dass das nicht zerlegt wird und stattdessen die Software das neue Modell unterstützt. (z.B. Navi-software, etc.) Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? ist das so schwer?! ja schon. Wenn das automatisch gehen soll schon. der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. Wenn man mit Himmelsrichtungen für die Straßenseite arbeitest, dann hast Du das Problem, dassw man bei schräg verlaufenden Straßen nicht weiss, ob das nun nördlich ist (wie bei einer horizontalen Straße), oder schon westlich (wie bei einer senkrechten Straße) ... verstehst Du? Da müssten dann wieder Regeln eingeführt werden, ab wieviel ° was gilt. Aber es wäre durch Regeln umsetzbar. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:17 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:44:33 schrieb steffterra: Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich etwas übersehen? inklusive Fahrspurtagging. tagging ja - zeichnen nein. Nur die Fahrbahnen der beiden Richtungen (die je aus mind. 2 Fahrspuren bestehen können) werden einzeln gezeichnet, da es ja eine bauliche Trennung für die Fahrbahnen der beiden Richtungen gibt. Einzelne Fahrspuren einer Fahrbahn sind darin nicht umgesetzt worden, da sie nicht baulich getrennt sind. Das Prinzip möchte ich ja in meinem Modell beibehalten, nur dass dann angepassten Editoren die ways als zu einer Fahrbahn gehörig dargestellen können (durch die gleiche Hintergrundfarbe). Insofern wird zwar aufgehoben: "ein way pro Fahrbahn", doch das gilt immernoch ausserhalb der gemeinsamen Hintergrundfarbe. Alte Editoren zeigen es halt wie jetzt auch an, mit den einzelnen ways pro Fahrspur, die aber nicht als baulich verbunden gezeigt werden (da die gemeinsame Hintergrundfarbe fehlt.) Ausserdem sind die ways ohne Straßenklassifizierung, weil das ja am datenway liegt. Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. Da Konzept sollte wohl auch fuer andere Strassen erweitert werden, leider kamm dann erstmal nix mehr... weil die bauliche Nicht-Trennung dagegen stand. Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. Irgendwie musst du die Gruppierung ja in der Datenbank speichern. Das naheliegendste ist da natuerlich eine einfache Relation. Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ sinnvoll), die dieses Model bietet. wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts "Gruppe" selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf "meine" Weise zu relaisieren... Da müsst Ihr Euch leider noch etwas gedulden. Aus beruflichen Gründen bin ich massiver eingespannt, als ich dachte und bin froh, diesem Thread weiter verfolgen zu können. mir geht's da leider aehnlich... Aber hey, wenn am Ende was brauchbares rauskommt, kommt's auf ein paar Tage mehr auch nicht an ;-) Sorry, muss weiter vertrösten. Aber ich stehe hinter meinem Modell und werde es hoffentlich bald mal machen können. Bis denn und danke, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
