Am 06.02.2011 17:22, schrieb Sven Anders:
Nachdem ich mich durch den Wald an Nachrichten zu diesem Thema gewühlt
habe und es so aussieht als ob sich langsam was sinnvolles aus der
Diskussion ergibt, habe ich noch ein paar Anmerkungen:
Ja, genau das habe ich mit dem Aufbau des TMC Validators [1]
Am 6. Februar 2011 20:26 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Ganz kurzer Hinweis:
Die Idee mit der Unterstützung von Namensräumen im Editor habe ich vor
drei Tagen hier geäußert (Betreff war Doppelpunkt).
Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen
Am 07.02.2011 13:05, schrieb M∡rtin Koppenhoefer:
Das Problem liegt beim Ausblenden halt immer darin, dass die Daten
auch wenn sie grundverschieden sind, sich in aller Regel doch
aufeinander beziehen. Wenn irgendwo ein Kino als Punkt eingezeichnet
ist, und man die benachbarte Straße verschiebt,
Am 06.02.2011 17:22, schrieb Sven Anders:
Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es
gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine
Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.)
Wenn Du die Beschleunigungs-Verzögerungsspuren meinst bei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 05.02.2011 19:32, schrieb Frederik Ramm:
Das Problem ist doch, dass da - egal wie viel ein Editor was zuklappt -
irgendwelche semantisch schwer verstaendlichen Zusatzinformationen an einem
Node haengen. Wieso hat diese Ampel hier Zusatztags,
Hallo.
Am Sonntag 06 Februar 2011, 10:01:04 schrieb Bodo Meissner:
Die Warnmeldung könnte dann aussagen: Lieber User, mit diesem Objekt hier
ist irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier
etwas kaputtgeht. Darum kümmern sich ggf. die Spezialisten.
Und was soll das dann
Am 06.02.2011 01:58, schrieb Frederik Ramm:
Hallo,
Garry wrote:
TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man
einen riesen Aufwand um diese Fixpunkte mit externen Lösungen zu
finden ist die ganze Sache Wertlos.
Ich bin nicht ueberzeugt, dass es sich hier um einen
Garry und Frederik Ramm schrieben eine Menge
Hallo
Eure Diskussion ist zwar schön und gut, doch sie führt irgendwie zu nichts.
So wie ich Frederik verstehe, geht es ihm darum, dass das ganze zu
komplex ist und Mapper abschreckt, weil sie Angst ahben Fehler zu
machen. Das kann ich durchaus
Am 06.02.2011 10:01, schrieb Bodo Meissner:
Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig
automatisch feststellen kann, ob die TMC-Tags noch konsistent sind.
Ja, genau das habe ich mit dem Aufbau des TMC Validators [1] bezweckt.
Er hat sicherlich viele Schwächen
Hallo,
Sven Anders wrote:
Frederik, ist es für dich okay, das wir mit einem Neuentwurf für ein TMC
Schema bis nach der Fossgis warten? Oder sollen wir schon jetzt einen
Neuentwurf anfangen?
fuer mich ok? Ich bin ja schon froh, wenn mir ueberhaupt jemand zuhoert ;)
Bye
Frederik
--
Frederik
Ganz kurzer Hinweis:
Die Idee mit der Unterstützung von Namensräumen im Editor habe ich vor
drei Tagen hier geäußert (Betreff war Doppelpunkt).
Die Reaktionen waren eher mäßig und skeptisch bezüglich der generellen
Umsetzbarkeit.
Da Du selbst dich da nicht beteiligt hast, hier das einfach
Hier nochmals mein letzter Senf dazu bis zur FOSSGIS :-:
* Namensräume ein/ausblenden im Editor wären wohl nützlich.
* Wanderwege und ÖPNV-Relationen widersprechen meines Wissens nicht
der Knoten-Kanten-Relationen-Tags-Struktur von OSM.
* Die aktuellen TMC-Tags missbrauchen den Prefix m.E.: tmc:
Hallo,
ich sehe das Problem eher darin begründet, dass unsere Editoren nicht
besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste
bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen,
mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und
Hallo,
André Reichelt wrote:
ich sehe das Problem eher darin begründet, dass unsere Editoren nicht
besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste
bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen,
mehrere Tags gleichen Namensraumes in der Software
Am 5. Februar 2011 19:32 schrieb Frederik Ramm frede...@remote.org:
Diese Loesung geht, im konkreten Fall TMC, am Problem vorbei.
dem stimme ich natürlich auch zu
Unsere
Daten duerfen sich nicht in eine staendig komplexere Richtung entwickeln, so
dass sie nur noch von Experten gepflegt
Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt
hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade
machen willst, kann Folgen haben, die Du nicht verstehst und die wir
hier leider auch
Hallo,
André Reichelt wrote:
Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt
hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade
machen willst, kann Folgen haben, die Du nicht verstehst und
Am 05.02.2011 22:44, schrieb Frederik Ramm:
In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig
weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei
regelmaessige automatische Veraenderungen von OSM fuer mehr
TMC-Konformitaet stattfinden, und dass Benutzer,
Am 05.02.2011 22:44, schrieb Frederik Ramm:
Wir haben vielleicht festgestellt, dass es nicht trivial ist; aber
nicht, dass man es nicht kann. Es braucht halt ein bisschen
Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden
kompliziert und OSM bleibt einfach, als umgekehrt.
Hallo Ulf,
Ulf Lamping wrote:
Es ist dir vielleicht nicht bewußt, aber das was du damit letztlich
forderst ist nichts anderes als sowas wie die Relevanzkriterien der
deutschen Wikipedia. Das gehört nicht hier her, das muß hier weg.
Es hat schon immer bei OSM die Auffassung gegeben, dass wir
Hallo,
Garry wrote:
TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man einen
riesen Aufwand um diese Fixpunkte mit externen Lösungen zu finden ist
die ganze Sache Wertlos.
Ich bin nicht ueberzeugt, dass es sich hier um einen Riesenaufwand
handelt. Ich koennte mir vorstellen,
Am 02.02.2011 23:40, schrieb Frederik Ramm:
Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese Datenbank separat waere.
Die
Hallo,
On 02/03/11 09:20, Garry wrote:
Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese Datenbank separat waere.
Die TMC-Daten
Am 03.02.2011 09:26, schrieb Frederik Ramm:
Hallo,
On 02/03/11 09:20, Garry wrote:
Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender es einfacher haette,
wenn diese
Am 3. Februar 2011 10:05 schrieb Henning Scholland o...@aighes.de:
Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher
auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte
zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden
Hallo,
On 02/03/11 10:05, Henning Scholland wrote:
Ich glaube es wäre in OSM einfacher abzubilden und für die Router
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an
die entsprechenden OSM-Wege tagt.
Hi,
Henning Scholland schrieb:
Am 03.02.2011 09:26, schrieb Frederik Ramm:
Hallo,
On 02/03/11 09:20, Garry wrote:
Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am
einfachsten ist. Was den Speicherort der Datenbank 2 betrifft,
glaube ich aber, dass der potentielle Anwender
Hi,
Frederik Ramm schrieb:
On 02/03/11 10:05, Henning Scholland wrote:
Ich glaube es wäre in OSM einfacher abzubilden und für die Router
einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern
die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an
die
Hallo,
Sorry meinen grundsätzlichen Einwurf... Ich kenne TMC etwas und
interessiere mich immer, wie ein externe Fachinformationssysteme (FIS)
und OSM zusammenarbeiten können und kann Frederiks Bedenken in diesem
Falle nachvollziehen.
Nun scheint ja ein Kompromiss zu entstehen, denn eine Löschung
On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote:
...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
übertragen.
NA - an der Grenze fuer NRW sind die Daten aber dran - Also der
TMC Location code ...
On Thu, 2011-02-03 12:13:29 +0100, Florian Lohoff f...@zz.de wrote:
On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote:
...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur
gesprochen vom Radio-Moderator, sondern wird eben auch via TMC
übertragen.
NA - an der
Am 03.02.2011 10:44, schrieb Frederik Ramm:
Hallo,
On 02/03/11 10:05, Henning Scholland wrote:
Bsp:
Auf dem OSM-Weg verläuft nur eine Richtung:
(1234)---(5678) -- TMC:forward=1234:5678
oder
(1234)---(5678) -- TMC:backward=1234:5678
Was waere der Unterschied zwischen
Am 02.02.2011 22:56, schrieb Frederik Ramm:
Hallo,
On 02/02/11 21:16, Sven Anders wrote:
Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein
funktionierendes TMC Schema zu entwerfen.
Marcus hat ein Schema fuer Maschinen entworfen. OSM ist aber fuer
Menschen. Fuer Menschen ist
Hallo,
Am Mittwoch 02 Februar 2011 21:16:57 schrieb Sven Anders:
sehr viel sinnvollen Text
+1
Gruß, Wolfgang
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Hallo,
On 02/03/2011 02:59 PM, Sven Anders wrote:
Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang
sagst du nicht ich will das und das ändern und das beißt sich mit TMC.
Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne
Fuehrerschein bedienbar ist. Dass man
Ih möchte da Frederik etwas die Stange halten.
Die Erläuterungen zu TMC und das TMC Schema entsprechen z.zT. wirklich
nicht den Regeln der sinnvoller OSM-Schemas. Ich beziehe mich auf die
Schema-Diskussion oben und den wohl relevanten Artikel
Hallo,
ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank.
Ich habe nicht die Uebersicht, wer da alles dran arbeitet und dran
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen
ehrbaren Mappern auf die Fuesse trete, aber wenn's nach mir geht, muss
das Zeug
Hallo Frederik,
ich selber finde die TMC-Daten ganz ok. - auch wenn diese kryptisch sind
und für Menschen nicht verständlich... Unten sind noch ergänzende Worte...
Am 02.02.2011 11:10, schrieb Frederik Ramm:
Hallo,
Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand
mal
Hallo,
On 02/02/11 11:34, Fred Jelk wrote:
Mir sieht das nach einem grossangelegten Designfehler aus. Da haette
man von vornherein ein OSM-externes Mapping TMC-OSM bauen muessen,
statt praktisch die ganze TMC-Datenbank auf OSM aufzupropfen.
Da sehe ich dann das Problem, wenn man ein
Am 02.02.11 11:10, schrieb Frederik Ramm:
Hallo,
ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich
habe nicht die Uebersicht, wer da alles dran arbeitet und dran
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen
ehrbaren Mappern auf die Fuesse trete, aber
Hallo
Solche kryptischen Dinge gibt es bei Importen recht häufig. Die
Hausnummern in Dänemark haben zich Tags, die man in OSM nicht bräuchte.
In Italien schwirren auch einige herum.
Ich verstehe, dass man irgendsowas braucht, um bspw. später Updates zu
fahren. Aber meiner Meinung nach gehört
Hallo,
Am Mittwoch 02 Februar 2011 11:10:25 schrieb Frederik Ramm:
Hallo,
[ ]
Vielleicht kann mir mal einer den folgenden Vorgang erklaeren.
Da ist also eine harmlose Ampel in Dortmund, Node-ID 270090818, getaggt
als highway=traffic_signals.
Dann kommt am 31, Januar der User ruhri
Hi,
Fred Jelk schrieb:
Am 02.02.2011 11:10, schrieb Frederik Ramm:
Hallo,
Mir erschliesst sich der Nutzen dieser Tags nicht - kann mir jemand
mal eine praktische Anwendung zeigen, die diese Tags benutzt?
Wenn ich mich nicht irre, werden die TMC-Daten von openrouteservice
ausgewertet
Am 02.02.2011 11:53, schrieb Henning Scholland:
Hallo
Solche kryptischen Dinge gibt es bei Importen recht häufig. Die
Hausnummern in Dänemark haben zich Tags, die man in OSM nicht
bräuchte. In Italien schwirren auch einige herum.
Ich verstehe, dass man irgendsowas braucht, um bspw. später
Ich bin gegen ein Löschen der TMC-Daten.
Richtig ist zwar, dass relativ viele Information zusätzlich
gespeichert werden, welche nicht immer notwendig sind, da sie einfach
von einem Bot hinzugefügt werden können. Aber ein genereller Abgleich
ist nicht fehlerfrei möglich.
Marcus Wohlschon (der
On 02.02.11 12:33, Pascal Neis wrote:
ich wollte bei der FOSSGIS nach meinem
Vortrag auch eine Diskussion diesbzgl. starten, etwas
überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten
in OSM eingearbeitet werden?
Ich kenne die Natur dieser TMC Daten/Location Codes nicht, grundsätzlich
Am 2. Februar 2011 11:10 schrieb Frederik Ramm frede...@remote.org:
Wir haben fast aussschliesslich menschenlesbare Daten in OSM. Schnapp Dir
ein beliebiges Objekt, und Du kannst in aller Regel verstehen, was die Tags
daran bedeuten.
ich kenne die Details der TMC-Daten nicht, aber durch das
Hallo,
Am Mittwoch 02 Februar 2011 12:34:46 schrieb Peter Wendorff:
Am 02.02.2011 11:53, schrieb Henning Scholland:
Hallo
Solche kryptischen Dinge gibt es bei Importen recht häufig. Die
Hausnummern in Dänemark haben zich Tags, die man in OSM nicht
bräuchte. In Italien schwirren auch
Hi,
Andreas Labres schrieb:
On 02.02.11 12:33, Pascal Neis wrote:
ich wollte bei der FOSSGIS nach meinem
Vortrag auch eine Diskussion diesbzgl. starten, etwas
überspitzt: Macht es Sinn, wie (ob) derzeit die TMC Daten
in OSM eingearbeitet werden?
Ich kenne die Natur dieser TMC Daten/Location
Hallo,
On 02/02/11 13:12, Wolfgang wrote:
Ich würde bei 1:1-Zuordnungen nicht einmal eine ID in die OSM-Datenbank
einfügen, sondern diese Verknüpfung in der extra-DB oder einer dritten
Verknüpfungsinstanz halten.
Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das
On 02.02.11 14:05, Pascal Neis wrote:
TMC Staus oder Verkehrsbehinderungen beziehen sich
im Normalfall immer auf Straßenstücke.
Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC. Und die gilt
es in OSM identifizierbar zu machen (IMO). Wenn dazu die Strategie des Taggens
geändert
On Wed, 2011-02-02 14:19:50 +0100, Andreas Labres l...@lab.at wrote:
On 02.02.11 14:05, Pascal Neis wrote:
TMC Staus oder Verkehrsbehinderungen beziehen sich
im Normalfall immer auf Straßenstücke.
Das wäre auch mein Verständnis/meine praktische Erfahrung mit TMC.
Und die gilt es in OSM
On Wed, 2011-02-02 14:22:50 +0100, Frederik Ramm frede...@remote.org wrote:
On 02/02/11 12:34, Peter Wendorff wrote:
Das Wiki dokumentiert eigentlich insgesamt recht gut, was da gemacht
wird und welches Tagging-Schema verwendet wird.
Also offensichtlich gibt es da eine TMC-Datenbank mit
Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org:
Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das
funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am
Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche,
Hallo,
Am Mittwoch 02 Februar 2011 14:07:53 schrieb Frederik Ramm:
Hallo,
Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf
die externe Datenbank linkt - aber das skaliert nicht, oder im
Volksmund: Wenn das jeder machen wuerde ;)
Das sehe ich in diesem Fall komplett
Hallo.
Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang:
DIe TMC-Geschichte gehört zu den
zentralen Daten, die zumindest mit OSM eng vermascht werden müssen.
Routing mit Verkehrsinfo ist einfach Stand der Technik.
Aber ist nicht einerseits die Datenübertragung des TMC und auch die
On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurst be...@bwurst.org wrote:
Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang:
DIe TMC-Geschichte gehört zu den
zentralen Daten, die zumindest mit OSM eng vermascht werden müssen.
Routing mit Verkehrsinfo ist einfach Stand der Technik.
Moin,
Am 02.02.2011 15:56, schrieb Wolfgang:
Hallo,
Am Mittwoch 02 Februar 2011 14:07:53 schrieb Frederik Ramm:
Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf
die externe Datenbank linkt - aber das skaliert nicht, oder im
Volksmund: Wenn das jeder machen wuerde ;)
Hallo.
Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw:
Aber ist nicht einerseits die Datenübertragung des TMC und auch die
Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik
und wird das nicht in Zukunft sowieso anders laufen?
Veraltet? Naja, Das
Hallo,
On 02/02/11 16:52, Frank Gruender wrote:
TMC ist funktional direkt auf Navigationssysteme ausgelegt und nicht für
Mikrowellen und Waschmaschinen. Die Aktualität dürfte in der Regel
größer als bei Telefonnummern irgendwelcher Restaurants sein. OSM ist
gerade für Navigationssyteme und für
Am 02.02.11 schrieb Jan-Benedict Glaw:
Einfache Mappings sind mit TMC so nicht zu machen.
was ist, wenn Du die Location-Codes der Punkte an die verbindenden Ways
hängst? z.B. bei oneways (Autobahnen):
tmc_ref=12345-54321 / tmc_ref=54321-12345
und bei normalen Straßen
Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw:
On Wed, 2011-02-02 14:19:50 +0100, Andreas Labresl...@lab.at wrote:
On 02.02.11 14:05, Pascal Neis wrote:
TMC Staus oder Verkehrsbehinderungen beziehen sich
im Normalfall immer auf Straßenstücke.
Das wäre auch mein Verständnis/meine praktische
Hallo!
Ich seh das eher generisch. Beim Durchforsten von Tags, die häufig vorkommen
aber nicht gerendert werden, bin ich auf viele unterschiedliche kryptische
Referenzen, IDs und Spezialtaggings gestoßen, meist mit eigenem Prefix,
deren Sinnhaftigkeit sich dem Normalmapper nicht erschließt.
Am 2. Februar 2011 17:16 schrieb Frederik Ramm frede...@remote.org:
Und warum TMC:cid_58:tabcd_1:... - muss man davon ausgehen, dass es die
gleichen LocationCodes auch im Namensraum TMC:cid_59:tabcd_1 oder
TMC:cid_58:tabcd_2 gibt?
cid ... Land 58
Es kann vorkommen, dass Straßen oder Bereiche
On Wed, 2011-02-02 17:02:37 +0100, Bernd Wurst be...@bwurst.org wrote:
Am Mittwoch 02 Februar 2011, 16:35:38 schrieb Jan-Benedict Glaw:
UKW gibts für lau. Bzw. gegen GEZ-Gebühr. Wifi und UMTS gibts nur
gegen Extra-Geld, die Technik ist (denk' auch an die Navis) teurer und
komplizierter.
Am 02.02.2011 15:37, schrieb Jan-Benedict Glaw:
Die übrigen Nutzer merken nicht viel von den TMC-Tags.
Was soll ein Mapper denn tun, wenn er eine Straße mit
TMC-Tags ändern will. Wenn eine Kreuzung zum Kreisverkehr
umgebaut wurde, eine Straße mit zwei getrennten Fahrbahnen
bislang nur als eine
On Wed, 2011-02-02 18:23:00 +0100, Henning Scholland o...@aighes.de wrote:
Am 02.02.2011 15:26, schrieb Jan-Benedict Glaw:
Problematisch ist, daß die Punkte/Strecken/Polygone nicht trivial auf
die OSM-Gegenstücke übertragbar sind. Es gibt beispielsweise
straßentechnisch nicht das Kreuz
Am 02.02.2011 11:10, schrieb Frederik Ramm:
Hallo,
ich aegere mich ziemlich ueber die TMC-Daten in der OSM-Datenbank. Ich
habe nicht die Uebersicht, wer da alles dran arbeitet und dran
gearbeitet hat, also es besteht die Gefahr, dass ich jetzt einigen
ehrbaren Mappern auf die Fuesse trete, aber
Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org:
Natuerlich kann man das Problem umgehen, indem man aus OSM heraus auf die
externe Datenbank linkt - aber das skaliert nicht, oder im Volksmund: Wenn
das jeder machen wuerde ;)
Komischerweise hast Du bei Photos eine andere
Hallo,
On 02/02/11 19:34, Jan-Benedict Glaw wrote:
Für Straßen kann man grob sagen, daß es deren Enden meistens mit
Kreuzungen oder Ab-/Auffahrten übereinstimmen. Bei Regionen ist das
nicht mehr ganz so einfach.
Aber Regionen koennten ja wiederum sehr gut in einer vollstaendig
externen
Hallo,
On 02/02/11 21:16, Sven Anders wrote:
Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein
funktionierendes TMC Schema zu entwerfen.
Marcus hat ein Schema fuer Maschinen entworfen. OSM ist aber fuer
Menschen. Fuer Menschen ist dieses Schema nicht wartbar.
Leider gab es
Am 02.02.2011 22:56, schrieb Frederik Ramm:
Hallo,
On 02/02/11 21:16, Sven Anders wrote:
Bei TMC ist halt das Problem: Eine Anwendung macht erst Sinn, wenn man
die Daten hat, die Daten kann man erst Sinnvoll in ein Schema pressen,
wenn man weiß was die Anwendung können soll.
Deshalb habe ich
Hallo,
On 02/02/11 23:17, Ulf Lamping wrote:
Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten
sein muessen, um genutzt werden zu koennen?
Ich bin davon überzeugt, das diese Daten direkt in OSM enthalten sein
sollten, wenn der Aufwand für einen potentiellen Anwender der
Hallo Bernd,
On 02.02.2011 16:19, Bernd Wurst wrote:
Aber ist nicht einerseits die Datenübertragung des TMC und auch die
Herangehensweise wie die TMC-Codes definiert sind stark veraltete Technik und
wird das nicht in Zukunft sowieso anders laufen?
Weiß jemand wie TMCpro hier arbeitet? Auch mit
On 02.02.2011 16:35, Jan-Benedict Glaw wrote:
On Wed, 2011-02-02 16:19:59 +0100, Bernd Wurstbe...@bwurst.org wrote:
Am Mittwoch 02 Februar 2011, 15:56:03 schrieb Wolfgang:
Übertragungen auch nötig sind oder ob die das auf die für mich naheliegendere
Weise machen: Von Koordinate [X] bis
On 02.02.11 22:39, Frederik Ramm wrote:
Aber Regionen koennten ja wiederum sehr gut in einer vollstaendig externen
Datenbank auf Koordinaten gemappt werden, oder? Also z.B. Region 1234 =
Polygon(Koordinatenpaar, Koordinatenpaar, ...) - das ist ja nun nicht
notwendig, dass wir da die exakte
76 matches
Mail list logo
