From krischdel at gmx.de Wed Oct 4 13:10:16 2006 From: krischdel at gmx.de (Krischdel@gmx.de) Date: Wed, 4 Oct 2006 13:10:16 +0200 Subject: [opengeodb] Location Skript Message-ID: <20061004111115.DD19B9225F@leipzig.mushaake.org> Hallo Ihr Männer, ich finde die Möglichkeiten der OpenGeoDB total klasse!!!! Grosses Lob dafür. Ich soll für meinen Cheffin eine Umkreissuche auf unserer Homepage machen. Wegen Eurer guten Erklärungen im Internet habe ich es geschafft die OpenGeoDB einzuspielen und die GeoClass und das PEAR zu installieren. Das Location.php Skript läuft nun endlich und zeichnet auch die Karte, allerdings zeigt er mir die Orte in 10km Entfernung nicht an. Habt Ihr eine Idee was ich falsch mache?! :-( Bin echt verzweifelt und meine Cheffin ist der festen Überzeugzeugung, dass ich als Webdesignerin so was können muss… Funktioniert das “findCloseByGeoObjects” aus der Geoclass 0.3.1 vielleicht nicht richtig? Habe ich vielleicht meine Serverumgebung falsch eingestellt? Ich bin verzweifelt. Ich benutze die aktuellste PEAR , OpenGeoDB und GeoClass Version. Bin dankbar für jeden Tipp. Liebe Grüsse, Kristina -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20061004/d2b02aa4/attachment.html From mirko.steiner at slashdevslashnull.de Thu Oct 5 12:56:00 2006 From: mirko.steiner at slashdevslashnull.de (Mirko Steiner) Date: Thu, 05 Oct 2006 12:56:00 +0200 Subject: [opengeodb] WGS84: "umkreis" berechnung? Message-ID: <4524E4C0.9050105@slashdevslashnull.de> Hallo :) ich habe folgendes problem: ich möchte eine orts koordinate abspeichern und dazugehörig noch ein umfeld berechnen z.B. 50km. Vereinfacht (und das ist auch durchaus okay so) möchte ich das nicht als kreis sondern lediglich als viereckige fläche. ich habe mal bissel was vorbereitet, also wie ich auf die koordinaten von frankfurtkomme ist klar, durch die opengeo db aber wie kalkuliere ich jetzt als beispiel jetzt 25km nach links und 25km nach oben für punkt2, und 25km nach unten und 25km nach rechts für punkt3? danke schonmal im vorraus hier der link zum bild: http://slashdevslashnull.de/pickle/picKLE-albums/google-earth/opengeodb.jpg From krischdel at gmx.de Fri Oct 6 10:42:45 2006 From: krischdel at gmx.de (Krischdel@gmx.de) Date: Fri, 6 Oct 2006 10:42:45 +0200 Subject: [opengeodb] Location Skript Message-ID: <20061006084405.E043C1636C@leipzig.mushaake.org> Habt Ihr denn keine Idee? hmm … Funktioniert das Location Skript denn bei Euch? Zusammen mit der aktuellsten GeoClass und OpenGeoDB? Bin über jeden Tipp dankbar. Liebe Grüsse, Kristina -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20061006/6ab02379/attachment-0001.html From d.leske at freenet.de Sat Oct 7 18:57:55 2006 From: d.leske at freenet.de (d.leske at freenet.de) Date: Sat, 07 Oct 2006 18:57:55 +0200 Subject: [opengeodb] Max. und Min.werte von Lon/Lat? Message-ID: Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20061007/f858090d/attachment.html -------------- nächster Teil -------------- Hiho, welche Maximal- und Minmalwerte für Längen- und Breitengrad wurden für die Landkarte in der Demo(*) benutzt? Bräuchte die zum exakten Umrechnung der Grade in Pixelangaben. Gruß Denni (*) http://opengeodb.hoppe-media.com/examples/location.php From wolfgang.uhr at devsup.de Mon Oct 9 21:07:14 2006 From: wolfgang.uhr at devsup.de (Wolfgang Uhr) Date: Mon, 9 Oct 2006 21:07:14 +0200 Subject: [opengeodb] Anmeldung eines neuen ... Message-ID: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> Einen wunderschönen guten Tag Ich bin Softwareentwickler und habe über OpenBc auf diese Seite gefunden. Dann hatte ich mich eingetragen in diese Liste und erst einmal reingehört. Nachdem hier aber kaum bis gar nicht gepostet wird, versuche ich es einfach einmal und stelle mich entsprechend vor (http://applikationssoftware.de/). Ich weiß zur Zeit nicht, wie aktuell die Webseite ist und ob tatsächlich zum Beispiel bei den Daten noch irgendwelcher Bedarf besteht. Aus der Webseite geht hervor, dass die Daten eine Beziehung herstellen zwischen der Postleitzahl bzw. dem Ortsnamen und den Geokoordinaten. Es geht aber nicht hervor, ob zum Beispiel alle Orte, bzw. alle Postleitzahlenbereiche bereits erfasst sind oder ob noch welche fehlen. Hier würde mich einfach einmal eine %-Angabe interessieren und ggf. auch eine Angabe der noch nicht erschlossenen Gebiete. Herzliche Grüße Wolfgang Uhr From mirko.steiner at slashdevslashnull.de Mon Oct 9 21:25:31 2006 From: mirko.steiner at slashdevslashnull.de (Mirko Steiner) Date: Mon, 09 Oct 2006 21:25:31 +0200 Subject: [opengeodb] Anmeldung eines neuen ... In-Reply-To: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> Message-ID: <452AA22B.2050008@slashdevslashnull.de> Wolfgang Uhr schrieb: > Einen wunderschönen guten Tag > > Ich bin Softwareentwickler und habe über OpenBc auf diese Seite gefunden. > Dann hatte ich mich eingetragen in diese Liste und erst einmal reingehört. > Nachdem hier aber kaum bis gar nicht gepostet wird, versuche ich es einfach > einmal und stelle mich entsprechend vor (http://applikationssoftware.de/). > > Ich weiß zur Zeit nicht, wie aktuell die Webseite ist und ob tatsächlich zum > Beispiel bei den Daten noch irgendwelcher Bedarf besteht. Aus der Webseite > geht hervor, dass die Daten eine Beziehung herstellen zwischen der > Postleitzahl bzw. dem Ortsnamen und den Geokoordinaten. Es geht aber nicht > hervor, ob zum Beispiel alle Orte, bzw. alle Postleitzahlenbereiche bereits > erfasst sind oder ob noch welche fehlen. Hier würde mich einfach einmal eine > %-Angabe interessieren und ggf. auch eine Angabe der noch nicht > erschlossenen Gebiete. > > Herzliche Grüße > Wolfgang Uhr > Hallo Wolfgang, auf der sourceforge seite ist ein bissel doku wie man mit der datenbank umgeht, ist ganz einfach und nicht schwer zu verstehen. Deutschland ist was die postleitzahlen,vorwahlen und geographischen daten angeht sehr gut abgedeckt, im umland wirds bissel schwieriger, ich glaube schweiz und österreich da geht noch was aber das wars auch schon. ich kann dir zum stand auch wenig sagen ob da noch was gemacht wird, ob sich jemand um weiter daten kümmert und ob das durch probleme verhindert wird. mfg mirko From traut at gmx.de Tue Oct 10 09:45:28 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 09:45:28 +0200 Subject: [opengeodb] Anmeldung eines neuen ... In-Reply-To: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> Message-ID: <20061010074528.GQ17777@trokan.micronas.com> On 2006-10-09 21:07, Wolfgang Uhr wrote: > Einen wunderschönen guten Tag > > Ich bin Softwareentwickler und habe über OpenBc auf diese Seite gefunden. > Dann hatte ich mich eingetragen in diese Liste und erst einmal reingehört. Willkommen! > Nachdem hier aber kaum bis gar nicht gepostet wird, versuche ich es einfach > einmal und stelle mich entsprechend vor (http://applikationssoftware.de/). > > Ich weiß zur Zeit nicht, wie aktuell die Webseite ist und ob tatsächlich zum > Beispiel bei den Daten noch irgendwelcher Bedarf besteht. Immer > Aus der Webseite > geht hervor, dass die Daten eine Beziehung herstellen zwischen der > Postleitzahl bzw. dem Ortsnamen und den Geokoordinaten. Es geht aber nicht > hervor, ob zum Beispiel alle Orte, bzw. alle Postleitzahlenbereiche bereits > erfasst sind oder ob noch welche fehlen. Die Postleitzahlenbereiche sind vollstaendig, die Gemeinden haben wir auch - verbesserungsfaehig ist die Genauigkeit ihrer Koordinatgen. Grosse Luecken ergeben sich bei den Ortschaften und Ortsteilen darunter. > Hier würde mich einfach einmal eine > %-Angabe interessieren und ggf. auch eine Angabe der noch nicht > erschlossenen Gebiete. Bezogen auf Deutschland: Gemeinden wuerde ich schaetzen 98 % (denn gerade in den neuen Bundeslaendern wird noch immer fusioniert). Genauigkeit: bei ca. 50 % wuerde ich die Genauigkeit auf eine Viertel Gradminute schaetzen. Das koennte noch verbessert werden. Schoenen Gruss Martin From list at tridemail.de Tue Oct 10 09:58:23 2006 From: list at tridemail.de (Michael Borchers) Date: Tue, 10 Oct 2006 09:58:23 +0200 Subject: [opengeodb] deutschlandkarte als bild References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> <20061010074528.GQ17777@trokan.micronas.com> Message-ID: <000601c6ec41$dc8ac870$af24a8c0@mbpc> hallo, wir arbeiten an einem skript mit der text_plz bank, dieses zeichnet wie gewohnt punkte basierend auf den koordinaten auf eine deutschlandkarte. allerdings scheint unsere karte unproportional. gibt es in dem opengeo projekt eine fertige karte oder eine funktion, die diese malt?! danke From traut at gmx.de Tue Oct 10 14:50:09 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 14:50:09 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <1160483970.452b948280220@www.domainfactory-webmail.de> References: <1160483970.452b948280220@www.domainfactory-webmail.de> Message-ID: <20061010125009.GD24199@trokan.micronas.com> On 2006-10-10 14:39, Martin Brenda wrote: > Seit mein Projekt offiziell online ist, kommt es immer wieder vor, dass einzelne > Orte, die fehlen, hinzugefügt werden müssen. Zur Zeit nehme ich hierzu > irgendeine loc_id und erstelle alle notwendigen Einträge. Wenn aber später von > OpenGeoDB diese loc_id's für andere Orte / Länder oder was auch immer verwendet > werden sollten, so müsste ich alle meine Daten abändern. Gibt es irgendwo eine > Übersicht, welche loc_id für welche Länder verwendet werden sollen / dürfen? Im Moment ist das voellig frei. Ich selbst hatte fuer Oesterreich Nummern ab 4310000000 vergeben (Laendervorwahl 43, Erweiterung um Orts- und Gemeindeschluessel). Suche dir am einfachsten einen bisher weit ab gelegenen, ungenutzten Bereich. Thomas vergibt in der Regel beim Zusammenfuehren von Bestaenden komplett neue Nummern. > OpenGeoDB ist bei mir Teil meines CMS. Ich überlege für dieses CMS ein neues > OpenGeoDB-Modul zu erstellen (Webfrontend) über das neue Daten auf einfache > Weise angelegt werden können. Dieses Modul könnte ich anschließend auch dem > Projekt zur Verfügung stellen, falls gewünscht. Diese Arbeit könnte man auch > zusammen koordinieren. Ja, mach' bitte mal - sowas brauchen wir noch immer, auch wenn ich selbst sowas am liebsten unter einer wiki-Oberflaeche haette. Ich koennte mir auch gut vorstellen, dass deine Erweiterungen z.B. monatlich oder bei Ueberschreiten von 50 neuen Eintraegen an diese Liste hier zur Abnahme/Korrektur geschickt wuerden. Schoenen Gruss Martin From traut at gmx.de Tue Oct 10 15:26:28 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 15:26:28 +0200 Subject: [opengeodb] =?iso-8859-1?q?Daten_der_Statistischen_=C4mter_des_Bu?= =?iso-8859-1?q?ndes_und_der_L=E4nder?= In-Reply-To: <20061010131610.40300.qmail@web26205.mail.ukl.yahoo.com> References: <20061010131610.40300.qmail@web26205.mail.ukl.yahoo.com> Message-ID: <20061010132628.GA24250@trokan.micronas.com> On 2006-10-10 15:16, Thomas Müller wrote: > Ich habe nur einen Hinweis gefunden, dass man die > jeweiligen Internet-Seiten als Quelle angeben muss. Da hast du schon den wiederspruch zwischen OPENgeodb und diesen Daten. > Leider bin ich kein Jurist und habe keinerlei Ahnung > von den unterschiedlichen Lizenzen. Die Daten bieten sich je nach Notwendigkeit und Eignung fuer den privaten Gebrauch an. Vielleicht waere es sinnvoll, solche Quellen zu sammeln und zu dokumentieren. Trag's doch einfach auf http://de.giswiki.net/index.php/OpenGeoDB ein! http://de.giswiki.net/wiki/Datenquellen Schoenen Gruss Martin From amuelle1 at gmx.de Tue Oct 10 15:38:14 2006 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 10 Oct 2006 15:38:14 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061010125009.GD24199@trokan.micronas.com> Message-ID: <058b01c6ec71$58b90d60$3844820a@nbandreas> Hallo zusammen, wäre es in dem Zusammenhang nicht besser man verzichtet komplett auf ID's für die Datenübergabe an die zentrale Stelle? Dazu könnte man doch eine geeignete XML Struktur entwickeln die dann vollkommen ohne ID's auskommt. Diese XML Pakete kann Thomas dann importieren und vergibt damit zentral einmalig eine ID. An sich ist dieses ID problem der Hauptgrund warum ich meine Datenbestände bisher nicht mit OpenGeoDB verbinde und Daten bereitstelle da ich auf dem Rückweg meine Daten unter einer ganz anderen ID wieder zurück gekommen würde. Das dann alles wieder auseinander zu bekommen ist mir im Moment zu kompliziert und zu risikoreich (doppelte ID's, verschobene ID's usw.) Gruß, Andreas From sn at heise.de Tue Oct 10 15:49:07 2006 From: sn at heise.de (Sven Neuhaus) Date: Tue, 10 Oct 2006 15:49:07 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <058b01c6ec71$58b90d60$3844820a@nbandreas> References: <058b01c6ec71$58b90d60$3844820a@nbandreas> Message-ID: <452BA4D3.7030007@heise.de> Andreas Müller wrote: > wäre es in dem Zusammenhang nicht besser man verzichtet komplett auf ID's > für die Datenübergabe an die zentrale Stelle? Nein. Es gibt ja nicht nur neue Datensätze, sondern auch Korrekturen. Ohne eine eindeutige ID lässt sich nicht feststellen welcher Datensatz geändert wurde. Gruss, -Sven From amuelle1 at gmx.de Tue Oct 10 16:57:25 2006 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 10 Oct 2006 16:57:25 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <452BA4D3.7030007@heise.de> Message-ID: <00d901c6ec7c$65d908a0$e70000c0@nbandreas> Hallo Sven, ein XML für Datenänderungen darf doch ein ID als Referenz haben - da spricht ja nichts gegen. Aber eben die eine die einmal festgelegt wurde und das an zentraler Stelle. Gruß, Andreas From wolfgang.uhr at devsup.de Tue Oct 10 20:02:29 2006 From: wolfgang.uhr at devsup.de (Wolfgang Uhr) Date: Tue, 10 Oct 2006 20:02:29 +0200 Subject: [opengeodb] Anmeldung eines neuen ... In-Reply-To: <20061010074528.GQ17777@trokan.micronas.com> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> <20061010074528.GQ17777@trokan.micronas.com> Message-ID: <452BE035.7050205@devsup.de> Hallo Sorry aber ich muss doch noch mal nachfragen ... Martin Trautmann schrieb: > Die Postleitzahlenbereiche sind vollstaendig, die Gemeinden haben wir auch - verbesserungsfaehig ist die Genauigkeit ihrer Koordinatgen. Steht irgendwo, was das konkret bedeutet? Also ich frage mal ganz dumm: a) Postleitzahlenbereiche sind vollstaendig vollständig heißt: Die Liste aller Postleitzahlen ist vollständig, nicht aber die zugehörigen Koordinaten? b) die Gemeinden haben wir auch Also die Liste der Gemeinden, die habt ihr. c) verbesserungsfaehig ist die Genauigkeit ihrer Koordinatgen. Was sind "genaue" Koordinaten und was sind "ungenaue". Woher weiß man, was was ist? Habt ihr zum Beispiel in meinem Wohnort 75328 Schömberg irgendwelche Probleme? Gibt es dazu irgendwo eine Erklärung? Herzliche Grüße Wolfgang Uhr From amuelle1 at gmx.de Tue Oct 10 20:17:31 2006 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 10 Oct 2006 20:17:31 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <200610101936.52712.martin.brenda@brendaonline.de> Message-ID: <025101c6ec98$5a17ef60$e70000c0@nbandreas> Hallo Martin, ich bin jetzt mal gemein und sag ich hab aber meine eigene ID und will da nicht 5688 als new übergeben sondern 0815. Jeder Datenlieferant hat seine eigene ID. Entweder man macht es so das jeder Datenlieferant einen ID Bereich zugewiesen bekommt den er dann verwenden kann - oder eine ID wird nur an einer zentralen Stelle vergeben. Was soll denn z.B. passieren wenn du und ich die die gleichen Daten aber mit unterschiedlichen ID's einliefern ? Das muss in die Hose gehen da hoffentlich nur ein Datensatz überleben wird und einer von uns auf seine ID verzichten muss. Aus meiner Erfahrung im Automobil-Bereich kann ich dezentrale ID's nicht empfehlen. Das führt am Ende zu permanenten Abstimmungsprobleme wann denn nun welche ID durch welche zu ersetzen ist - oder wenn man Kollisionen ignoriert hat man irgendwann alle Datensätze mehrfach. Deswegen sagte ich ja in meinem ersten Posting dazu das neue (das hatte ich vergessen zu betonen) Daten ohne eine ID eingeliefert werden. Bestehende Daten werden natürlich immer über ihre ID referenziert. Das ermöglicht auch den Datenanlieferern ihre internen Daten so zu gestalten das sie interne ID's haben die sich gegen die einmaligen unveränderlichen ID's von OpenGeoDB mappen können. Alle Datensätze die ein Lieferant dort bei sich einstellt haben KEINE OpenGeoDB ID. Importiert man nun OpenGeoDB Daten muss man in einem Lauf alle eigenen Datensätze ohne OpenGeoDB ID anhand ihres Inhalts in der OpenGeoDB suchen und wenn gefunden die nun vorhandene ID übernehmen. Daher würde ich in so einen Szenario meine eigenen GeoDaten Stuktur haben die nur auf eine OpenGeoDB referenziert. Daher kann man die OpenGeoDB importieren wann man will und aus den Daten seine Daten abgleichen (insert, update, delete). Rückwärts gehen bei einem OpenGeoDB Update eigene Daten nicht zwangsweise verloren und können abgegelichen werden falls sie nun auf einmal auftauchen. ... neues Objekt ... bestehendes Objekt Der Witz an der XML Struktur ist das sie in sich geschlossen ist und keine ID für Referenzen benötigt. Damit entstehen einfach in sich geschlossene Datenhäppchen. Gruß, Andreas From traut at gmx.de Tue Oct 10 21:49:52 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 21:49:52 +0200 Subject: [opengeodb] Anmeldung eines neuen ... In-Reply-To: <452BE035.7050205@devsup.de> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> <20061010074528.GQ17777@trokan.micronas.com> <452BE035.7050205@devsup.de> Message-ID: On 10. Oct 2006, at 20:02, Wolfgang Uhr wrote: > Hallo > > Sorry aber ich muss doch noch mal nachfragen ... Aber gerne doch > Martin Trautmann schrieb: >> Die Postleitzahlenbereiche sind vollstaendig, die Gemeinden haben wir > auch - verbesserungsfaehig ist die Genauigkeit ihrer Koordinatgen. > > Steht irgendwo, was das konkret bedeutet? Nein. Die Frage ist aber akademisch: Wo willst du bei einer Fläche über etliche Quadradatkilometer hinweg deren repräsentative Koordinate hinlegen? > a) Postleitzahlenbereiche sind vollstaendig > > vollständig heißt: Die Liste aller Postleitzahlen ist vollständig, > nicht > aber die zugehörigen Koordinaten? Nein, wir haben nicht nur alle PLZ, sondern auch alle mit Koordinate. > b) die Gemeinden haben wir auch > > Also die Liste der Gemeinden, die habt ihr. Ja - und beim augenblicklichen Ansatz haben alle auch eine Koordinate. Ich selbst würde den Ansatz bevorzugen, dass vorübergehend auch schon bekannte Orte noch ohne Koordinate enthalten wären - das würde schon offensichtlich zeigen, wo noch Arbeit zu tun wäre. > c) verbesserungsfaehig ist die Genauigkeit ihrer Koordinatgen. > > Was sind "genaue" Koordinaten und was sind "ungenaue". Woher weiß man, > was was ist? Naja, ganz einfach: genaue Koordinaten sind genau und ungenaue sind ungenau ;-) Ich hatte ja schon geschrieben: < Genauigkeit: bei ca. 50 % wuerde ich die Genauigkeit auf eine Viertel < Gradminute schaetzen. Das koennte noch verbessert werden. > Habt ihr zum Beispiel in meinem Wohnort 75328 Schömberg irgendwelche > Probleme? Ich habe hier auf möglicherweise veralteten Daten. Aber die nennen für Schömberg bei Neuenbürg: 8.65000 / 48.78330 Das sind typische Koordinaten für ein relativ ungenaues Raster - es gibt noch einige weitere Orte mit 48.78330 und 8.65000. Ursache dafür ist die Datenquelle: NIMA-Daten mit genau dieser ursprünglichen Auflösung. Demzufolge könntest du also für die Gemeinde hier genauere Daten heraussuchen. Ebenso könntest du z.B. alle Einträge heraussuchen, die auf genau diesen Rasterstufen liegen und die Koordinaten zurechtrücken. Konkretes Problem: Diese Koordinaten sind zugleich die der Gemeinde, wie auch des Ortes Schömberg. Du kannst auch prüfen, ob die Koordinaten nun repräsentativ für den Ort oder für die Gemeinde sind - denn Bieselsberg, Charlottenhöhe, Langenbrand, Oberlengenhardt oder Schwarzenberg fehlen bisher noch in der opengeodb. Alles Klar? Martin From wendorff at uni-paderborn.de Tue Oct 10 23:48:12 2006 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 10 Oct 2006 23:48:12 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061010125009.GD24199@trokan.micronas.com> References: <1160483970.452b948280220@www.domainfactory-webmail.de> <20061010125009.GD24199@trokan.micronas.com> Message-ID: <452C151C.6070902@uni-paderborn.de> Kann man nicht für die locid-Vergabe einen Webservice einrichten? Einfachste Variante: der spuckt einfach eine bisher ungenutzte locid für ein neues Objekt aus. Nächst-komplexere Variante: Aufgrund der angegebenen Daten werden bestehende Objekte zum Vergleich angegeben und eine optional zu verwendende neue ID. Eine neue locid zu generieren sollte nicht so schwer sein, denke ich - das sollte mit einer SQL-Abfrage über eine aktuelle opengeodb machbar sein, Suche nach bestehenden Daten ist ebenfalls nicht sooo schwierig - abgesehen davon, dass man entsprechende Unschärfe etc berücksichtigen sollte. Das Problem mit eindeutigen oder eben nicht eindeutigen IDs wäre damit jedenfalls halbwegs gelöst - lediglich die unter Umständen großen Mengen vergebener und später nicht gebrauchter Locids müsste man irgendwie in den Griff kriegen. mfg Peter Wendorff Martin Trautmann schrieb: > On 2006-10-10 14:39, Martin Brenda wrote: > >> Seit mein Projekt offiziell online ist, kommt es immer wieder vor, dass einzelne >> Orte, die fehlen, hinzugefügt werden müssen. Zur Zeit nehme ich hierzu >> irgendeine loc_id und erstelle alle notwendigen Einträge. Wenn aber später von >> OpenGeoDB diese loc_id's für andere Orte / Länder oder was auch immer verwendet >> werden sollten, so müsste ich alle meine Daten abändern. Gibt es irgendwo eine >> Übersicht, welche loc_id für welche Länder verwendet werden sollen / dürfen? >> > > Im Moment ist das voellig frei. Ich selbst hatte fuer Oesterreich Nummern > ab 4310000000 vergeben (Laendervorwahl 43, Erweiterung um Orts- und > Gemeindeschluessel). > > Suche dir am einfachsten einen bisher weit ab gelegenen, ungenutzten > Bereich. Thomas vergibt in der Regel beim Zusammenfuehren von Bestaenden > komplett neue Nummern. > > >> OpenGeoDB ist bei mir Teil meines CMS. Ich überlege für dieses CMS ein neues >> OpenGeoDB-Modul zu erstellen (Webfrontend) über das neue Daten auf einfache >> Weise angelegt werden können. Dieses Modul könnte ich anschließend auch dem >> Projekt zur Verfügung stellen, falls gewünscht. Diese Arbeit könnte man auch >> zusammen koordinieren. >> > > Ja, mach' bitte mal - sowas brauchen wir noch immer, auch wenn ich selbst > sowas am liebsten unter einer wiki-Oberflaeche haette. > > Ich koennte mir auch gut vorstellen, dass deine Erweiterungen z.B. > monatlich oder bei Ueberschreiten von 50 neuen Eintraegen an diese Liste > hier zur Abnahme/Korrektur geschickt wuerden. > > Schoenen Gruss > Martin > From traut at gmx.de Tue Oct 10 22:04:01 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 22:04:01 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <200610101936.52712.martin.brenda@brendaonline.de> References: <058b01c6ec71$58b90d60$3844820a@nbandreas> <200610101936.52712.martin.brenda@brendaonline.de> Message-ID: <29a953c72eeba96a4c92489988e2fc36@gmx.de> On 10. Oct 2006, at 19:36, Martin Brenda wrote: > Eine ID wird, wie bereits erwähnt, benötigt. Man könnte aber ein > zusätzliches > Attribut setzen, um zu kennzeichnen ob es sich um ein neues oder > bereits > existrierendes Objekt handelt. Ja, das ist das einfachste. Als Attribute empfehlen sich - Quelle: opengeodb oder lokal erstellt (dein "new" bedeutet ja lokal neu, ohne bedeutet's aus der opengeodb - Datum der Erstellung - ein indirektes Indiz, ob ein Eintrag nach der letzten Release hinzugefügt wurde - evtl. auch Datum der Änderung oder Hinweise, was sich genau geändert hat >> An sich ist dieses ID problem der Hauptgrund warum ich meine >> Datenbestände >> bisher nicht mit OpenGeoDB verbinde und Daten >> bereitstelle da ich auf dem Rückweg meine Daten unter einer ganz >> anderen ID >> wieder zurück gekommen würde. Bei mir kein Problem - ich verwende die opengeodb-IDs eben nur als Sekundaerschluessel. Schönen Gruß Martin From traut at gmx.de Tue Oct 10 21:59:38 2006 From: traut at gmx.de (Martin Trautmann) Date: Tue, 10 Oct 2006 21:59:38 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <200610101925.54883.martin.brenda@brendaonline.de> References: <1160483970.452b948280220@www.domainfactory-webmail.de> <20061010125009.GD24199@trokan.micronas.com> <200610101925.54883.martin.brenda@brendaonline.de> Message-ID: <05e57f43721b01a40b9def65d1d556b7@gmx.de> On 10. Oct 2006, at 19:25, Martin Brenda wrote: >> Suche dir am einfachsten einen bisher weit ab gelegenen, ungenutzten >> Bereich. Thomas vergibt in der Regel beim Zusammenfuehren von >> Bestaenden >> komplett neue Nummern. > > Genau dies würde ich gerne vermeiden. Die loc_id wird bei mir (wie > bestimmt > auch bei vielen anderen) als Foreign Key in anderen (eigenen) Tabellen > verwendet. Wenn beim Zusammenführen die loc_id geändert wird, so > müsste ich > bei einem Update auf eine neue OpenGeoDB-Version alle relevanten > loc_id's > nachziehen. Sonst passiert es, dass sich ein angelegtes Objekt auf > einmal > statt in Stuttgart in Hamburg oder sonstwo befindet. Du müsstest deine eigenen Einträge eben wegwerfen, sobald es dafür Einträge aus der opengeodb gibt. > Deshalb ging meine Frage in die Richtung, ob die Vergabe dieser > loc_id's > irgendwo zentral koordiniert werden könnte, so dass ich z.B. einen > neuen Ort > an euch schicke, mit einer von mir vergebenen loc_id, und diese dann > erhalten > bleibt bzw. mir gleich mitgeteilt wird, wie die letztendliche loc_id > sein > wird, so dass ich dies auch gleich bei mir nachziehen kann. Gleich ist > besser > als irgendwann später, wenn bereits einige Objekte mit Foreign Keys > auf diese > loc_id erstellt wurden. Derartiges gibt es aber bisher nicht - und derzeit werden auch keine externen loc_ids übernommen, egal wie sinnvoll diese wären. Das ist einfach so bei der Art, wie bisher opengeodb aktualisiert wird. Das kannst du gut finden, oder nicht - aber die Releases erfolgen eben auf diese Art und durch diesen Flaschenhals. >> Ich koennte mir auch gut vorstellen, dass deine Erweiterungen z.B. >> monatlich oder bei Ueberschreiten von 50 neuen Eintraegen an diese >> Liste >> hier zur Abnahme/Korrektur geschickt wuerden. > > Können wir so machen. Ich schicke also einmal im Monat meine Daten an > diese > Liste. Wie wollt ihr sie haben? Als fertige SQL-Statements? Ich lege > immer > SQL-Statements an. Zum Import ist SQL am besten - aber zur Diskussion auf der Liste taugt's nicht. An der Stelle würde ich eher ein Textformat mit .csv empfehlen. Das ist leichter lesbar und verständlich. Schönen Gruß Martin From list at lab.at Wed Oct 11 09:27:29 2006 From: list at lab.at (Andreas Labres) Date: Wed, 11 Oct 2006 09:27:29 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <452C151C.6070902@uni-paderborn.de> References: <1160483970.452b948280220@www.domainfactory-webmail.de> <20061010125009.GD24199@trokan.micronas.com> <452C151C.6070902@uni-paderborn.de> Message-ID: <452C9CE1.3090205@al.lab.at> Peter Wendorff wrote: > Kann man nicht für die locid-Vergabe einen Webservice einrichten? Entschuldige, das halte ich für eine denkbar schlechte Idee. Für jedes Insert ein Webservice-Call? Wenn, dann ist nur die Anforderung einer Range sinnvoll, ähnlich wie IP-Adressen, wo man zu RIPE geht und ein /18 beantragt (und damit dann eine Zeit lang auskommt). Aber da muß es dann - ich bleibe bei der Analogie mit den IP-Adressen - ein WHOIS Service geben, wo man nachsehen kann, wem was wofür gegeben wurde. In Summe aber IMO Kanonen auf Spatzen. Eher sollte man die darunterliegenden Probleme lösen... /al From sn at heise.de Wed Oct 11 09:33:16 2006 From: sn at heise.de (Sven Neuhaus) Date: Wed, 11 Oct 2006 09:33:16 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <1160547444.452c8c74480c4@www.domainfactory-webmail.de> References: <025101c6ec98$5a17ef60$e70000c0@nbandreas> <1160547444.452c8c74480c4@www.domainfactory-webmail.de> Message-ID: <452C9E3C.1050202@heise.de> Martin Brenda wrote: > Es müssen auf jeden Fall zentrale IDs sein. Das Problem ist aber folgendes: wenn > ich einen Ort in meiner DB brauche, dann brauche ich ihn sofort. Ich kann nicht > die Daten an OpenGeoDB weiterleiten und dann auf das nächste Update warten. > Wenn ich die Daten nun in meine DB einpflege und sie dann an OpenGeoDB > weiterleite, dann würde ich gerne die loc_id beibehalten können bzw. sofort > eine Nachricht bekommen, dass diese sich ändert und zwar in diese und diese > neue loc_id. Dann kann ich die loc_id in meiner DB beibehalten bzw. gleich > nachziehen. Ich habe keine Interesse, alle diese Abgleiche später, beim > nächsten Update auf eine neue OpenGeoDB zu machen. Dies erschwert die > Angelegenheit nur. Man könnte einen solchen Mechanismus sicherlich aufsetzen, geprüft werden können die Daten aber wohl nicht sofort, insofern kann es vorkommen dass eine ID dann wieder entzogen wird, da der Datensatz nicht korrekt oder ungültig war. > Ich glaube unsere Ansichten sind gar nicht so verschieden. Im Endeffekt müsste > es eine zentrale Vergabe von loc_id's geben, ob automatisiert oder per Hand ist > zweitrangig (automatisiert wäre aber sinnvoller, im Interesse des armen Hundes > der die Dinger sonst per Hand vergeben muss). Falls die Vergabe automatisch > erfolgen soll, so muss es irgendwo (ich nehme mal jetzt den Server an) eine > "aktuelle" Version von OpenGeoDB geben. Dort könnte man 1) überprüfen ob der > Ort, den ich eingeben will, nicht in der Zwischenzeit eingegeben wurde und 2) > immer eine noch freie loc_id bekommen, falls der Ort nicht existiert. Sehr hilfreich wäre in dem Zusammenhang auch wenn sich Benutzer, die Korrekturen oder Ergänzungen haben, alle (teils noch ungeprüften) Korrekturen einsehen können die seit dem letzten Release eingegangen sind - und die vorläufigen IDs die Ihnen zugewiesen wurden. Damit wird verhindert dass eine Korrektur mehrmals durchgeführt wird und mehrere vorläufige IDs für dieselber Korrektur vergeben werden von denen dann doch eine wieder entzogen wird. Im Prinzip also eine Echtzeit-Ansicht eines Teils der OpenGeoDB. -Sven From traut at gmx.de Wed Oct 11 09:53:56 2006 From: traut at gmx.de (Martin Trautmann) Date: Wed, 11 Oct 2006 09:53:56 +0200 Subject: [opengeodb] Nachfrage des Neuen ... In-Reply-To: <452C1812.7050402@devsup.de> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> <20061010074528.GQ17777@trokan.micronas.com> <452BE035.7050205@devsup.de> <452C1812.7050402@devsup.de> Message-ID: <0df4592b2138b526146f0107f370f17d@gmx.de> On 11. Oct 2006, at 0:00, Wolfgang Uhr wrote: > Also als Physiker interepretier ich nun > > 8.65000 +- 0.000005 / 48.78330 +- 0.000005 > > Und das ist mit Sicherheit falsch. Richtig. Alle Daten sind auf diese Dezimallänge erweitert. Die tatsächliche Genauigkeit ist geringer. Nimm einfach nur die Dezimalstellen und sieh dir deren Häufigkeitsverteilung an. Ich habe es gerade mal nachgesehen und muss mich selber korrigieren: Etwa 12000 von 15000 Einträgen haben eine Genauigkeit im Minutenraster, z.B. Min. Häufigkeit 42' 255 39' 249 44' 243 43' 236 40' 236 38' 236 35' 235 37' 233 ... 0' 153 29' 146 >> Das sind typische Koordinaten für ein relativ ungenaues Raster - es >> gibt >> noch einige weitere Orte mit 48.78330 und 8.65000. Ursache dafür ist >> die >> Datenquelle: NIMA-Daten mit genau dieser ursprünglichen Auflösung. >> Demzufolge könntest du also für die Gemeinde hier genauere Daten >> heraussuchen. > > Raussuchen? Wo sucht man solche Daten? Früher hat man für sowas einen > Sextanten genommen. Heute müsste es ein GPS-Empfänger eigentlich auch > tun. Aber irgenwann müsste mal einer konkret sagen, was er sich unter > "genau" vorstellt. Wie wär's mit nachdenken und eigene Vorstellung vorschlagen? Meine Vorstellung von genau wäre, dass die Koordinate zumindest innerhalb der zugehörigen Fläche liegt. 'Genau' wäre also etwas, wo sich die Anzahl der Dezimalstellen proportional zur Wurzel aus der Fläche verhält. Du kannst dir selber ausrechnen, welche Strecke einer Abweichung um eine halbe Minute entspricht. Einer der kleinen ist z.B. die Gemeinde Sengerich mit 1 km^2 Fläche und 20 Einwohnern. Aber ist es tatsächlich so relevant, diese Minigemeinde zu korrigieren? Von daher sollte man da eher top-down arbeiten und erst mal die Gemeinden mit besonders vielen Einwohnern durcharbeiten. >> Ebenso könntest du z.B. alle Einträge heraussuchen, die auf genau >> diesen >> Rasterstufen liegen und die Koordinaten zurechtrücken. > > Vorraussetzung dazu ist, dass ich verstehe, was gemeint ist - ich meine > das "Zurechtrücken"! Wird das nun klar? >> Konkretes Problem: Diese Koordinaten sind zugleich die der Gemeinde, >> wie >> uch des Ortes Schömberg. Du kannst auch prüfen, ob die Koordinaten nun >> repräsentativ für den Ort oder für die Gemeinde sind - denn >> Bieselsberg, >> Charlottenhöhe, Langenbrand, Oberlengenhardt oder Schwarzenberg fehlen >> bisher noch in der opengeodb. > > Das kann ich prüfen ja - wie prüft man sowas? Gegenfrage: wie würdest du denn die Koordinate eines Ortes herausfinden, um überhaupt etwas korrigieren zu können? Ein einfacher online-Ansatz ist, sich z.B. bei Google-Maps die Koordinate anzeigen zu lassen und dann sie so zu verschieben, dass sie tatsächlich über dem Ort liegt - das geht natürlich nur für Orte, nicht aber für Gemeinden, die mehrere getrennte Orte umfassen. Bei denen kannst du die Koordinate entweder auf den Schwerpunkt der Gemeindefläche legen, auf den Sitz der Gemeindeverwaltung (beachte, dass manche Gemeinden zu Ämtern zusammengeschlossen sind oder von der Nachbargemeinde mit verwaltet werden), du kannst statt dem geographischen Schwerpunkt aber z.B. auch den Schwerpunkt ermitteln über den Mittelwert der nach Einwohnern gewichteten Koordinaten der zugehörigen Orte. Beachte, dass bei z.B. C-förmig geformten Gemeinden die Koordinate dann auch ausserhalb der tatsächlichen Gemeindefläche liegen kann. Wie willst du dann vorgehen? Google-Map setzt voraus, dass deren Satellitenbilder auch tatsächlich korrekt ausgerichtet wären. Das stimmt zwar immer besser - aber den augenblicklichen Stand weiss ich nicht. Du kannst auch Kartenmaterial heranziehen und es damit abschätzen. Wenn's aber nicht gerade topographische Karten in ausreichender Auflösung sind, dann stellen andere Karten fast immer eine optische Vereinfachung zur besseren Lesbarkeit dar - haben also auch falsche Koordinaten. Mit Kartenmaterial in einer Auflösung von z.B. 1:100 000 wird das schon etwas ungenau (wie viel entspricht einer Minute in deiner Umgebung in Länge und Breite?). Mit 1:20 000 und bekannten Referenzpunkten kann man das schon recht genau interpolieren. Oder du fährst einfach mit deinen GPS-Empfänger hin... Vielleicht erklärt dir diese Nennung unterschiedlicher Ansätze, warum ich dir keine Definition von genau geben kann oder mag - letztendlich erfolgt ein Zurechtrücken nach subjektiv gewerteten Merkmalen. Manche machen das optisch nach Gefühl, manche tendieren in Richtung Ortsmittelpunkt (Marktplatz, Kirche). Betrachte z.B. den Münchner Marienplatz - das ist Referenzpunkt "0 km" auf den Entfernungsangaben. Einen Kilometer vor der Stadtgrenze werden dir noch immer viele Kilometer bis nach München angezeigt, eben jemen Referenzpunkt, der nicht einmal mehr mit dem privaten Kfz angefahren werden darf. Genau? Als Physiker weisst du doch genug über Modellbildung und Vereinfachung... Schönen Gruß Martin From opengeodb at ostertag.name Wed Oct 11 10:13:20 2006 From: opengeodb at ostertag.name (Joerg Ostertag) Date: Wed, 11 Oct 2006 10:13:20 +0200 Subject: [opengeodb] Nachfrage des Neuen ... genaue Position der Orte woher (OSM) In-Reply-To: <0df4592b2138b526146f0107f370f17d@gmx.de> References: <000a01c6ebd6$222708b0$030a0a0a@wsxpdev1> <452C1812.7050402@devsup.de> <0df4592b2138b526146f0107f370f17d@gmx.de> Message-ID: <200610111013.20331.opengeodb@ostertag.name> > Du kannst auch Kartenmaterial heranziehen und es damit abschätzen. > Wenn's aber nicht gerade topographische Karten in ausreichender > Auflösung sind, dann stellen andere Karten fast immer eine optische > Vereinfachung zur besseren Lesbarkeit dar - haben also auch falsche > Koordinaten. Mit Kartenmaterial in einer Auflösung von z.B. 1:100 000 > wird das schon etwas ungenau (wie viel entspricht einer Minute in > deiner Umgebung in Länge und Breite?). Mit 1:20 000 und bekannten > Referenzpunkten kann man das schon recht genau interpolieren. > > Oder du fährst einfach mit deinen GPS-Empfänger hin... Diese Lösung finde ich selber die beste, denn dann kannst du den GPS-Empfänger bei der Fahrt hin und zurück auch mitlaufen lassen und die gesammelten Daten dann gleich beim OpenStreetMap Projekt hoch laden, damit die dann Straßenkarten daraus machen können. Du kannst natürlich auch schauen, ob du in Openstreetmap zu diesem Ort schon Straßendaten existieren und deinen Punkt anhand des existierenden Straßen Materials ausrichten. Dazu würde ich idealerweise den OpenStreetMap Client josm verwenden. Diese Lösung hat den weiteren Vorteil, dass bezüglich "derivated work" und "Copyright der Daten" gar keine Frage aufkommt. -- Jörg Ostertag (München) http://www.ostertag.name/ From lnx at uzulabs.net Wed Oct 11 10:14:55 2006 From: lnx at uzulabs.net (Paul Puschmann) Date: Wed, 11 Oct 2006 10:14:55 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <452C9E3C.1050202@heise.de> References: <025101c6ec98$5a17ef60$e70000c0@nbandreas> <1160547444.452c8c74480c4@www.domainfactory-webmail.de> <452C9E3C.1050202@heise.de> Message-ID: <20061011081455.GB6655@linux.home.uzulabs.intern> On Wed, Oct 11, 2006 at 09:33:16AM +0200, Sven Neuhaus wrote: > Martin Brenda wrote: > > Es müssen auf jeden Fall zentrale IDs sein. Das Problem ist aber folgendes: wenn > > ich einen Ort in meiner DB brauche, dann brauche ich ihn sofort. Ich kann nicht > > die Daten an OpenGeoDB weiterleiten und dann auf das nächste Update warten. > > Wenn ich die Daten nun in meine DB einpflege und sie dann an OpenGeoDB > > weiterleite, dann würde ich gerne die loc_id beibehalten können bzw. sofort > > eine Nachricht bekommen, dass diese sich ändert und zwar in diese und diese > > neue loc_id. Dann kann ich die loc_id in meiner DB beibehalten bzw. gleich > > nachziehen. Ich habe keine Interesse, alle diese Abgleiche später, beim > > nächsten Update auf eine neue OpenGeoDB zu machen. Dies erschwert die > > Angelegenheit nur. > > Man könnte einen solchen Mechanismus sicherlich aufsetzen, geprüft werden > können die Daten aber wohl nicht sofort, insofern kann es vorkommen dass > eine ID dann wieder entzogen wird, da der Datensatz nicht korrekt oder > ungültig war. Ich würde alerdings vorschlagen die ID an dieser Stelle nicht "zu entziehen" und später einem anderen Eintrag zur Verfügung zu stellen, da die ID ja sicher in dem System des "Absenders" gespeichert ist. Ein ungültiger Antrag sollte dann zu einer gesperrten ID führen. So könnten auch Änderungen und Änderungswünsche sicher besser nachvollzogen werden. > > Ich glaube unsere Ansichten sind gar nicht so verschieden. Im Endeffekt müsste > > es eine zentrale Vergabe von loc_id's geben, ob automatisiert oder per Hand ist > > zweitrangig (automatisiert wäre aber sinnvoller, im Interesse des armen Hundes > > der die Dinger sonst per Hand vergeben muss). Falls die Vergabe automatisch > > erfolgen soll, so muss es irgendwo (ich nehme mal jetzt den Server an) eine > > "aktuelle" Version von OpenGeoDB geben. Dort könnte man 1) überprüfen ob der > > Ort, den ich eingeben will, nicht in der Zwischenzeit eingegeben wurde und 2) > > immer eine noch freie loc_id bekommen, falls der Ort nicht existiert. > > Sehr hilfreich wäre in dem Zusammenhang auch wenn sich Benutzer, die > Korrekturen oder Ergänzungen haben, alle (teils noch ungeprüften) > Korrekturen einsehen können die seit dem letzten Release eingegangen sind - > und die vorläufigen IDs die Ihnen zugewiesen wurden. Damit wird verhindert > dass eine Korrektur mehrmals durchgeführt wird und mehrere vorläufige IDs > für dieselber Korrektur vergeben werden von denen dann doch eine wieder > entzogen wird. > Im Prinzip also eine Echtzeit-Ansicht eines Teils der OpenGeoDB. Die Idee ist an sich gut. Kann ich unter einer vorläufigen ID soetwas wie eine Support-Ticket-Nummer verstehen, die lediglich meine Anfrage / Änderung nummeriert und dann später (nach erfolgreicher Prüfung) eine eindeutige ID zurückliefert? Hört sich soweit vom Ablauf interessant an. Paul -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 189 bytes Beschreibung: Digital signature URL : http://lists.phpbar.de/pipermail/opengeodb/attachments/20061011/fa5e8ed2/attachment.bin From wendorff at uni-paderborn.de Wed Oct 11 10:31:22 2006 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Wed, 11 Oct 2006 10:31:22 +0200 Subject: [opengeodb] =?iso-8859-15?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061011081455.GB6655@linux.home.uzulabs.intern> References: <025101c6ec98$5a17ef60$e70000c0@nbandreas> <1160547444.452c8c74480c4@www.domainfactory-webmail.de> <452C9E3C.1050202@heise.de> <20061011081455.GB6655@linux.home.uzulabs.intern> Message-ID: <452CABDA.4050202@uni-paderborn.de> Paul Puschmann schrieb: > On Wed, Oct 11, 2006 at 09:33:16AM +0200, Sven Neuhaus wrote: > >> Martin Brenda wrote: >> >>> Es müssen auf jeden Fall zentrale IDs sein. Das Problem ist aber folgendes: wenn >>> ich einen Ort in meiner DB brauche, dann brauche ich ihn sofort. Ich kann nicht >>> die Daten an OpenGeoDB weiterleiten und dann auf das nächste Update warten. >>> Wenn ich die Daten nun in meine DB einpflege und sie dann an OpenGeoDB >>> weiterleite, dann würde ich gerne die loc_id beibehalten können bzw. sofort >>> eine Nachricht bekommen, dass diese sich ändert und zwar in diese und diese >>> neue loc_id. Dann kann ich die loc_id in meiner DB beibehalten bzw. gleich >>> nachziehen. Ich habe keine Interesse, alle diese Abgleiche später, beim >>> nächsten Update auf eine neue OpenGeoDB zu machen. Dies erschwert die >>> Angelegenheit nur. >>> >> Man könnte einen solchen Mechanismus sicherlich aufsetzen, geprüft werden >> können die Daten aber wohl nicht sofort, insofern kann es vorkommen dass >> eine ID dann wieder entzogen wird, da der Datensatz nicht korrekt oder >> ungültig war. >> > > Ich würde alerdings vorschlagen die ID an dieser Stelle nicht "zu > entziehen" und später einem anderen Eintrag zur Verfügung zu stellen, > da die ID ja sicher in dem System des "Absenders" gespeichert ist. > Ein ungültiger Antrag sollte dann zu einer gesperrten ID führen. > > So könnten auch Änderungen und Änderungswünsche sicher besser > nachvollzogen werden. > > > >>> Ich glaube unsere Ansichten sind gar nicht so verschieden. Im Endeffekt müsste >>> es eine zentrale Vergabe von loc_id's geben, ob automatisiert oder per Hand ist >>> zweitrangig (automatisiert wäre aber sinnvoller, im Interesse des armen Hundes >>> der die Dinger sonst per Hand vergeben muss). Falls die Vergabe automatisch >>> erfolgen soll, so muss es irgendwo (ich nehme mal jetzt den Server an) eine >>> "aktuelle" Version von OpenGeoDB geben. Dort könnte man 1) überprüfen ob der >>> Ort, den ich eingeben will, nicht in der Zwischenzeit eingegeben wurde und 2) >>> immer eine noch freie loc_id bekommen, falls der Ort nicht existiert. >>> >> Sehr hilfreich wäre in dem Zusammenhang auch wenn sich Benutzer, die >> Korrekturen oder Ergänzungen haben, alle (teils noch ungeprüften) >> Korrekturen einsehen können die seit dem letzten Release eingegangen sind - >> und die vorläufigen IDs die Ihnen zugewiesen wurden. Damit wird verhindert >> dass eine Korrektur mehrmals durchgeführt wird und mehrere vorläufige IDs >> für dieselber Korrektur vergeben werden von denen dann doch eine wieder >> entzogen wird. >> Im Prinzip also eine Echtzeit-Ansicht eines Teils der OpenGeoDB. >> > > Die Idee ist an sich gut. > > Kann ich unter einer vorläufigen ID soetwas wie eine > Support-Ticket-Nummer verstehen, die lediglich meine Anfrage / > Änderung nummeriert und dann später (nach erfolgreicher Prüfung) eine > eindeutige ID zurückliefert? > Genau das halte ich für sinnvoll. Wenn irgendwann die freien locids knapp werden, kann man ja eventuell über die Einführung von Major-Releases nachdenken, die quasi nicht mehr mit eigenen Datenbeständen kompatibel sind, dafür aber alle IDs komplett wieder freigeben, die darin nicht enthalten sind. Häufig wird dies nicht notwendig sein, aber für den Fall der Fälle wäre das ein Ausweg. Auf diese Weise könnte man auch das Löschen nach einem Monat oder einem Jahr oder so rauslassen, was zu mehr Verwirrung und Problemen führen dürfte. Im Großen und Ganzen liefe auf diese Weise das System tatsächlich auf eine Art Bugtracking-System hinaus: - Fehlermeldungen - Bearbeitung der Fehler - Feature-Wünsche - Lösung/Einfügung der Features zusätzlich: - Direkte Fehlerkorrekturen/Einfügungen > Hört sich soweit vom Ablauf interessant an. > > Paul > dito Peter From stephan.s at gmx.net Fri Oct 13 08:48:18 2006 From: stephan.s at gmx.net (Stephan Schuster) Date: Fri, 13 Oct 2006 08:48:18 +0200 Subject: [opengeodb] OpenGeoDB unterstützen In-Reply-To: <200610130811.28583.martin.brenda@brendaonline.de> Message-ID: <20061013064831.41F541E23A1@leipzig.mushaake.org> On Fri, 13 Oct 2006 08:11:28 +0200, Martin Brenda wrote: >Hallo, > >um all die schönen Ideen umsetzen zu können, müssen einige >Grundvoraussetzungen erfüllt sein. Eine der wichtigsten ist das Vorhandensein >einer aktuellen OpenGeoDB-Version im Internet, in die alle neuen Einträge und >Änderungen eingepflegt werden können. Von dieser wird dann bei Bedarf ein >Release generiert. Ist die Voraussetzung bereits gegeben? Wenn nicht, ist so >etwas in Planung? Wie werden zur Zeit die Änderungen eingepflegt, lokal? Im Moment werden immer noch alle Daten von Thomas eingepflegt, der in unregelmässigen Abständen neue Versionen der Datenbank veröffentlicht. Von Zeit zu Zeit werden hier immer wieder mal Diskussionen angestoßen wie diese hier, in denen es darum geht openGeoDB besser nutzbar zu machen. Leider verlaufen die meistens nach einer kurzen Diskussion über die bestehende Datenstruktur o.ä. im Sand. >Durch eine Automatisierung des gesamten Prozesses (ich denke da immer an >www.musicbrainz.org als Vorbild) kann die Community besser genutzt werden, da >gewisse Hürden abgebaut werden. Das Einpflegen von neuen Datensätzen kann >trotzdem nur authentifizierten und authorisierten Benutzern gestattet werden, >so dass manche neue Daten anlegen und ändern dürfen, und nur einige wenige >auch Datensätze löschen können. Bei Bedarf könnte natürlich noch eine Abnahme >erfolgen, so dass die Datensätze erst nach Prüfung als aktiv gelten. Ich denke der nächste Schritt sollte sein eine Oberfläche zu schaffen über die neue Datensätze eingereicht werden können die von Benutzern mit Admin-Rechten überprüft und freigegeben werden. Es sollte mehrer Admins geben, damit das Projekt nicht von einer Einzelperson abhängig ist. Diese Oberfläche sollte auch einen Export in die bestehenden Formate ermöglichen. Morpheus hatte mal angekündigt nach Thomas' Vorgaben eine solche Oberfläche zu erstellen, aber seit dem gab es keine weitere Informationen zum Entwicklungsstand. Wie es scheint ist auch das gestorben, wenn nicht könnte Morpheus uns vielleicht kurz über den Stand informieren. Wie wohl bei den meisten hier (ich nehme mich da nicht aus und bin eigentlich auch nur stiller Mitleser) ist es wohl so, dass man aus irgendeinen Grund Geodaten benötigt, auf die OpenGeoDB stösst und das Projekt toll findet und mithelfen möchte. Leider scheitert dies meistens entweder am eigenen Zeitmangel, oder an mangelnder Koordination. Es gab sogar mal jemand der Geld in das Projekt investieren wollte, aber niemand wusste recht wofür es verwendet werden sollte und auch ein Mitarbeiter der c't hatte schonmal Hilfe angeboten. Meiner Meinung nach scheitern alle Ansätze hier meistens daran, dass von Anfang an ein perfektes Projekt angestrebt wird, das dann einfach nicht mit der zur Verfügung stehenden Zeit realisiert werden kann. Vielleicht sollten wir erst einmal die Minimalforderungen für die nächste Zukunft aufstellen. Unter http://opengeodb.hoppe-media.com/index.php?ToDo ist eigentlich schon ein brauchbarer Ansatz vorhanden, aber wie immer bleibt die Frage: wer machts? Stephan From traut at gmx.de Fri Oct 13 09:38:33 2006 From: traut at gmx.de (Martin Trautmann) Date: Fri, 13 Oct 2006 09:38:33 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061013064831.41F541E23A1@leipzig.mushaake.org> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013064831.41F541E23A1@leipzig.mushaake.org> Message-ID: <20061013073833.GC26557@trokan.micronas.com> On 2006-10-13 08:48, Stephan Schuster wrote: > Meiner Meinung nach scheitern alle Ansätze hier meistens daran, dass von > Anfang an ein perfektes Projekt angestrebt wird, das dann einfach nicht mit > der zur Verfügung stehenden Zeit realisiert werden kann. Vielleicht sollten > wir erst einmal die Minimalforderungen für die nächste Zukunft aufstellen. Hallo Stephan, es stimmt, dass hier von vielen Seiten eine solche Umsetzung versprochen wurde - und all das erst mal wieder im Sande verlief. Meine Hoffnung ist noch immer, dass sich jemand schon damit beschaeftigt, oder zumindest dies tun will, und dann ploetzlich eine gangbare Loesung vorgestellt wird. > Unter > > http://opengeodb.hoppe-media.com/index.php?ToDo > > ist eigentlich schon ein brauchbarer Ansatz vorhanden, aber wie immer > bleibt die Frage: wer machts? Das Problem ist nicht, aufzuschreiben, was zu tun ist - sondern das Problem ist schlichtweg: Es muss sich jemand hinsetzen und es tatsaechlich tun. Nicht alle Mitleser hier, nicht alle Anwender der Daten haben das Know-How, dies zu tun. Aber jeder, der's kann, ist gerne dazu aufgerufen, IRGENDWAS dazu ins Netz zu stellen. Das mag am Anfang vielleicht zur Zerfaserung der Bestaende fuehren - aber das Zusammenfuehren ist eigentlich keine besonders schwierige nachrangige Aufgabe. Bei unterschiedlichen Loesungen kann dann die Qualitaet entscheiden. Da es aber anscheinend muessig ist, auf die perfekte Umsetzung zu warten, sollte jetzt schon mal eine Minimalloesung angestrebt werden. Meine Minimalanforderung waere: Bei jedem Neueintrag muss zumindest dabeistehen, zu welcher Gemeinde er gehoert. Schoenen Gruss Martin From juergen.kappus at kamedia.de Fri Oct 13 15:09:28 2006 From: juergen.kappus at kamedia.de (=?iso-8859-1?Q?J=FCrgen_Kappus?=) Date: Fri, 13 Oct 2006 15:09:28 +0200 Subject: [opengeodb] Fehler in Datensatz Message-ID: <8AEEAB68FD53914F95F42A6B12B1B8AF09A78E@companyweb> openGeoDB: 86672 Baar Korrekt: 86674 Baar Ich hab noch nie mit Mailing Listen gearbeitet, ich hoffe so ist es richtig? ;)) Gruß Jürgen From mirko.steiner at slashdevslashnull.de Fri Oct 13 15:11:39 2006 From: mirko.steiner at slashdevslashnull.de (Mirko Steiner) Date: Fri, 13 Oct 2006 15:11:39 +0200 Subject: [opengeodb] Fehler in Datensatz In-Reply-To: <8AEEAB68FD53914F95F42A6B12B1B8AF09A78E@companyweb> References: <8AEEAB68FD53914F95F42A6B12B1B8AF09A78E@companyweb> Message-ID: <452F908B.6010308@slashdevslashnull.de> Jürgen Kappus schrieb: > openGeoDB: > 86672 Baar > > Korrekt: > 86674 Baar > > Ich hab noch nie mit Mailing Listen gearbeitet, ich hoffe so ist es richtig? ;)) > > Gruß > Jürgen hm ich nehme an du meinst die postleitzahl? :) From wendorff at uni-paderborn.de Fri Oct 13 17:11:30 2006 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Fri, 13 Oct 2006 17:11:30 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <200610131519.07572.martin.brenda@brendaonline.de> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013064831.41F541E23A1@leipzig.mushaake.org> <20061013073833.GC26557@trokan.micronas.com> <200610131519.07572.martin.brenda@brendaonline.de> Message-ID: <452FACA2.4050703@uni-paderborn.de> Martin Brenda schrieb: > Hallo! > URL: http://www.brendaonline.de/multiformo > Benutzername: Gast > Passwort: gast > > Das ganze läuft mit OpenGeoDB 0.2.4d. Ich habe vorerst nur das Einfügen neuer > Ortschaften implementiert. Und dieses Einfügen neuer Ortschaften funktioniert bisher auch ausschließlich mit einem Namen - sehe ich das richtig? Auch die Anzeige nur des Namens ist recht ungünstig, weil man dadurch bisher wenig tun kann. Aber es ist ein Anfang. > Es gibt noch vieles zu tun, ich werde aber nach > und nach alles notwendige implementieren. Zuerst möchte ich mich auf die für > mich wichtigen Dinge konzentrieren: Einfügen / Bearbeiten / Löschen neuer > Ortschaften mit Zuordnung zu Kontinent und Land. Das ganze baut auf meinem > CMS auf, da ich keine Lust habe Dinge wie Benutzerverwaltung, Rechtevergabe, > Templatesystem usw. neu aufzusetzen. Das CMS ist modular aufgebaut, so dass > einzelne Module (in diesem Fall das geodata-Modul) einfach hinzugefügt werden > können. Zwischen den einzelnen Modulen kann über die obere Leiste navigiert > werden (da wo links oben Basis steht). Kontinente sind noch nicht > implementiert. > Ich finde es gut, dass hier mal ein Ansatz sichtbar ist, aber das Modul für dein CMS zu basteln, das nicht OpenSource ist, finde ich ungünstig. Die opengeodb-Schnittstelle sollte und muss modular aufgebaut sein, so dass jeder weitermachen kann - insofern bist Du auf dem richtigen Weg. > Das geodata-Modul kann ich unter die LGPL stellen, so dass ihr es bei Bedarf > weiter ausbauen oder den Code in anderen Programmen verwenden könnt. Die > anderen Module kann ich leider nicht freigeben (im Sinne von OpenSource). Ich > kann dem OpenGeoDB-Projekt aber eine kostenlose Version zur Verfügung stellen > und das Projekt immer mit den neusten Versionen der Module (zur Zeit werden > core, overview und administration benötigt) versorgen. > Betrifft "die anderen Module" auch das Framework/CMS selbst? also auch Benutzerverwaltung etc? Viel mehr Module sehe ich dabei bisher nicht, aber mehr bräuchten wir ja auch nicht unbedingt. Allerdings wäre es eben nicht brauchbar, wenn wir letztendlich auf Dauer an Dich gebunden wären, weil wir das ganze nicht samt CMS auf einen anderen Server transferieren könnten, falls Du irgendwann ausfällst. > Wie gesagt: wenn von eurer Seite Interesse besteht auf dieser Basis etwas > aufzubauen, kann ich mir eine Zusammenarbeit gut vorstellen. > Also an sich ist der Ansatz zwar noch nicht weit, aber erstmal ja nicht schlecht. mfg Peter Wendorff From traut at gmx.de Fri Oct 13 19:02:19 2006 From: traut at gmx.de (Martin Trautmann) Date: Fri, 13 Oct 2006 19:02:19 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <452FACA2.4050703@uni-paderborn.de> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013064831.41F541E23A1@leipzig.mushaake.org> <20061013073833.GC26557@trokan.micronas.com> <200610131519.07572.martin.brenda@brendaonline.de> <452FACA2.4050703@uni-paderborn.de> Message-ID: <20061013170219.GQ28181@trokan.micronas.com> On 2006-10-13 17:11, Peter Wendorff wrote: > Martin Brenda schrieb: >> Hallo! >> URL: http://www.brendaonline.de/multiformo >> Benutzername: Gast >> Passwort: gast >> >> Das ganze läuft mit OpenGeoDB 0.2.4d. Ich habe vorerst nur das Einfügen neuer >> Ortschaften implementiert. > Und dieses Einfügen neuer Ortschaften funktioniert bisher auch > ausschließlich mit einem Namen - sehe ich das richtig? > Auch die Anzeige nur des Namens ist recht ungünstig, weil man dadurch > bisher wenig tun kann. > Aber es ist ein Anfang. Naive Frage: Wo kommt man da hin? Mehr als die Uebersicht von Gast wird mir nicht angezeigt. Auch in der sitemap deutet nichts auf opengeodb hin. > Ich finde es gut, dass hier mal ein Ansatz sichtbar ist, aber das Modul > für dein CMS zu basteln, das nicht OpenSource ist, finde ich ungünstig. Naja - mit den Daten kann jeder machen, was er will. Es gibt keinen Zwang zur Offenlegung der CMS-Module. > Die opengeodb-Schnittstelle sollte und muss modular aufgebaut sein, so > dass jeder weitermachen kann - insofern bist Du auf dem richtigen Weg. Von mir aus kann die Schnittstelle auch beliebig geschlossen bleiben. Wichtig waere mir vor allem, dass fuer den Rueckfluss der Daten auch die Aenderungen eben unmittelbar abrufbar waeren. >> Wie gesagt: wenn von eurer Seite Interesse besteht auf dieser Basis etwas >> aufzubauen, kann ich mir eine Zusammenarbeit gut vorstellen. >> > Also an sich ist der Ansatz zwar noch nicht weit, aber erstmal ja nicht > schlecht. Im Moment sehe ich leider gerade mal ein login - und fuer den Moment waere ich auch mit Dateneingabe ohne login einverstanden. Schoenen Gruss Martin From wendorff at uni-paderborn.de Fri Oct 13 19:36:51 2006 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Fri, 13 Oct 2006 19:36:51 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061013170219.GQ28181@trokan.micronas.com> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013064831.41F541E23A1@leipzig.mushaake.org> <20061013073833.GC26557@trokan.micronas.com> <200610131519.07572.martin.brenda@brendaonline.de> <452FACA2.4050703@uni-paderborn.de> <20061013170219.GQ28181@trokan.micronas.com> Message-ID: <452FCEB3.9050008@uni-paderborn.de> Martin Trautmann schrieb: > On 2006-10-13 17:11, Peter Wendorff wrote: > >> Martin Brenda schrieb: >> >>> Hallo! >>> URL: http://www.brendaonline.de/multiformo >>> Benutzername: Gast >>> Passwort: gast >>> >>> Das ganze läuft mit OpenGeoDB 0.2.4d. Ich habe vorerst nur das Einfügen neuer >>> Ortschaften implementiert. >>> >> Und dieses Einfügen neuer Ortschaften funktioniert bisher auch >> ausschließlich mit einem Namen - sehe ich das richtig? >> Auch die Anzeige nur des Namens ist recht ungünstig, weil man dadurch >> bisher wenig tun kann. >> Aber es ist ein Anfang. >> > > Naive Frage: Wo kommt man da hin? Mehr als die Uebersicht von Gast wird > mir nicht angezeigt. Auch in der sitemap deutet nichts auf opengeodb hin. > Oben rechts auf "Basis" zeigen - dann sollte das Menü aufklappen. Das ist designtechnisch etwas ungünstig, aber es geht - jedenfalls im aktuellen Firefox. > >> Ich finde es gut, dass hier mal ein Ansatz sichtbar ist, aber das Modul >> für dein CMS zu basteln, das nicht OpenSource ist, finde ich ungünstig. >> > > Naja - mit den Daten kann jeder machen, was er will. Es gibt keinen Zwang > zur Offenlegung der CMS-Module. > Das ist wohl richtig, aber sobald wir sowas zur quasi offiziellen Schnittstelle für die opengeodb-Administration machen, würde ich es doch begrüßen, wenn Bugfixes, Anpassungen etc eben nicht an einer Person hängen, sondern durch Quelloffenheit auch von anderen gefördert werden könnten. >> Die opengeodb-Schnittstelle sollte und muss modular aufgebaut sein, so >> dass jeder weitermachen kann - insofern bist Du auf dem richtigen Weg. >> > Von mir aus kann die Schnittstelle auch beliebig geschlossen bleiben. > Wichtig waere mir vor allem, dass fuer den Rueckfluss der Daten auch die > Aenderungen eben unmittelbar abrufbar waeren. > >>> Wie gesagt: wenn von eurer Seite Interesse besteht auf dieser Basis etwas >>> aufzubauen, kann ich mir eine Zusammenarbeit gut vorstellen. >>> >>> >> Also an sich ist der Ansatz zwar noch nicht weit, aber erstmal ja nicht >> schlecht. >> > Im Moment sehe ich leider gerade mal ein login - und fuer den Moment waere > ich auch mit Dateneingabe ohne login einverstanden. > siehe Oben. Dateneingabe ohne Login wäre sehr zu begrüßen - solange es dabei eine entsprechende Freigabeinstanz gibt. Sonst bringt uns das sicherlich nicht viel weiter. mfg Peter From traut at gmx.de Fri Oct 13 20:04:17 2006 From: traut at gmx.de (Martin Trautmann) Date: Fri, 13 Oct 2006 20:04:17 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <20061013175724.GR28181@trokan.micronas.com> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013064831.41F541E23A1@leipzig.mushaake.org> <20061013073833.GC26557@trokan.micronas.com> <200610131519.07572.martin.brenda@brendaonline.de> <452FACA2.4050703@uni-paderborn.de> <20061013170219.GQ28181@trokan.micronas.com> <452FCEB3.9050008@uni-paderborn.de> <20061013175724.GR28181@trokan.micronas.com> Message-ID: <20061013180417.GS28181@trokan.micronas.com> On 2006-10-13 19:57, Martin Trautmann wrote: > Aber wie gesagt, ich seh' noch nix. Autsch, jetzt habe ich mal JS auf maximal zulaessig erweitert. Jetzt sehe ich endlich auch mal in dezent grau 'Basis' oben links. Da komme ich dann nochmal zu Übersicht -> Übersicht Auch der Umweg ueber die Kontinente ist noch Neuland. .. Aber ueber Orte -> Deutschland sehe ich nun auch Seite 1 von 660 und habe gleich mal aaaalen geloescht... Fatal error: Unsupported operand types in /kunden/108762_74081/webseiten/brendaonline.de/multiformo/inc/functions.inc.php on line 80 Naja - dafuer konnte ich Hintertupfingen schon erfolgreich anlegen. Bloss kann ich den weder loeschen, noch editieren. Ein Anfang ist als gemacht... Schoenen Gruss Martin From traut at gmx.de Sat Oct 14 14:12:11 2006 From: traut at gmx.de (Martin Trautmann) Date: Sat, 14 Oct 2006 14:12:11 +0200 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_unterst=FCtzen?= In-Reply-To: <200610140921.30015.martin.brenda@brendaonline.de> References: <200610130811.28583.martin.brenda@brendaonline.de> <20061013175724.GR28181@trokan.micronas.com> <20061013180417.GS28181@trokan.micronas.com> <200610140921.30015.martin.brenda@brendaonline.de> Message-ID: <59ace9da33aefce46f5b69dd4d0c3975@gmx.de> On 14. Oct 2006, at 9:21, Martin Brenda wrote: >> Autsch, jetzt habe ich mal JS auf maximal zulaessig erweitert. > > Wieso Autsch?! Das ist eine ganz normale DHTML-Anwendung, wie es sie > immer > mehr im Netz gibt. Ohne JavaScript kommt man demnächst sowieso nicht > mehr > weit, AJAX sei dank. Nun gut - dann mögen andere das nutzen. Wenn unnötig JS verlangt wird, was genauso (einfacher und sicherer auch ohne ginge), dann ist das nix für mich. >> Da komme ich dann nochmal zu >> >> Übersicht -> Übersicht > > Wieso nochmal? Wie willst Du sonst aus einem anderen Modul auf die > Übersicht > kommen. Aus der Übersicht komme ich über den Link Übersicht zur Übersicht - und über das JS-Menü komme ich nochmals zur Übersicht. Ehrlichgesagt ist's mir lieber, wenn ich 1) nur die Links sehe, die mich auch weiterbringen 2) ich an den Links auch erkenne, wo sie hinführen. Dein JS-Ansatz ist hier mehrfach hinderlich: Ich finde den Link nur beim Herumstochern, ich sehe nicht auf welche Seite der Link mich führen wird, der Link sieht nicht aus wie ein typischer Link (Farbe, Unterstreichung), und der Link unterstützt keine visited-Farbgebung. Mag sein, dass der Vorteil von JS für den Entwickler gegeben ist. Für den Benutzer kann ich ihn nicht erkennen. > >> .. Aber ueber Orte -> Deutschland sehe ich nun auch Seite 1 von 660 >> und >> habe gleich mal aaaalen geloescht... >> >> Fatal error: Unsupported operand types in >> /kunden/108762_74081/webseiten/brendaonline.de/multiformo/inc/ >> functions.inc >> .php on line 80 > > Du hast es nicht gelöscht. Hier sollte eine Fehlermeldung kommen, dass > Du > nicht die notwendigen Rechte zum Löschen hast. Ok, sollte kommen. Gegenfrage: Warum sehe ich dann überhaupt einen Löschknopf? Ich halte den für durchaus sinnvoll: man sollte zumindest markieren, was man als löschwürdig einstuft. Löschen kann nach Prüfung dann jemand mit höheren Rechten. > >> Naja - dafuer konnte ich Hintertupfingen schon erfolgreich anlegen. >> >> Bloss kann ich den weder loeschen, noch editieren. >> >> Ein Anfang ist als gemacht... > > Hier scheint echt ein Mißverständins vorzuliegen. Ich hatte > geschrieben "dann > mache ich mal den ersten Schritt" und nicht "hier habt ihr das fertige > System". Ich wollte dadurch den Ansatz zeigen, wie eine Lösung von mir > aussehen könnte um die Diskussion über die Verwendbarkeit für OpenGeoDB > anzuregen. Das die meisten Dinge noch nicht funktionieren weiß ich > selbst. > Das war auch nicht Sinn dieser "Demo". Wozu soll ich eine Unmenge an > Zeit > investieren, wenn es dann am Ende heißt das passt uns nicht. Auf blöde > Kommentare und Gemeckere kann ich verzichten! Als genau diesen ersten kleinen Schritt habe ich das interpretiert. Aber wenn du auf Rückmeldungen verzichten kannst/willst, dann mache es bitte erst so weit fertig, bis es benutzbar ist. Wenn du nicht wissen willst, wie's auf den Anwender wirkt und welche Probleme er damit hat, dann hoffe ich für dich, dass dein Umgang mit Kunden anders verläuft - du wirkst hier recht dünnhäutig. Schönen Gruß Martin From jonasschaub at gmail.com Fri Oct 13 13:15:23 2006 From: jonasschaub at gmail.com (jonass) Date: Fri, 13 Oct 2006 04:15:23 -0700 (PDT) Subject: [opengeodb] alle plz eines landkreises bekommen Message-ID: <6793741.post@talk.nabble.com> hallo, wie erhalte ich denn alle postleitzahlen loc_ids aus einem bestimmten landkreis? also einmal zb. die stadt regensburg und einmal die des umkreises. komme mit den hierarchies an diesem punkt nicht wirklich weiter. -jonas -- View this message in context: http://www.nabble.com/alle-plz-eines-landkreises-bekommen-tf2436363.html#a6793741 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From stephan at webdesign-schuster.de Sun Oct 15 12:22:53 2006 From: stephan at webdesign-schuster.de (Stephan Schuster) Date: Sun, 15 Oct 2006 12:22:53 +0200 Subject: [opengeodb] OpenGeoDB unterstützen Message-ID: <20061015102214.AE04A18B1E@leipzig.mushaake.org> On Sat, 14 Oct 2006 09:21:29 +0200, Martin Brenda wrote: >> Autsch, jetzt habe ich mal JS auf maximal zulaessig erweitert. > >Wieso Autsch?! Das ist eine ganz normale DHTML-Anwendung, wie es sie immer >mehr im Netz gibt. Ohne JavaScript kommt man demnächst sowieso nicht mehr >weit, AJAX sei dank. Ich finde AJAX zwar eine durchaus positive Entwicklung mit viel Potential, allerdings sollte das immer eine Erweiterung der Funktionalität mit zusätzlichen Möglichkeiten darstellen und nicht die normale Benutzung erschweren. Trotz wachsender Verbreitung heisst das eben nicht, dass es überall verfügbar ist (wie Du ja grade sehen konntest). DHMTL-Menüs sollten zumindest durch eine alternative Menüstruktur in einem