[Talk-de] Mapnik Erstinstallation: Shoreline import mit shp2pgsql notwendig?
Hallo,
hoffentlich habe ich die richtige Kraut mit meiner Frage erwischt.
Einer Frage zu meiner "Sintflut-Weltkarte", also einer hellblauen Fläche ;-)
Ich habe gerade Mapnik 0.7.0 installiert, dazu die neueste SVN-Versionen von
osm2pgsql und "osm-mapnik" aus
http://svn.openstreetmap.org/applications/rendering/mapnik .
In der neueren Dokumentation steht nichts davon, daß man "shoreline_300"
und "processed_p", oder "world_pnd" per "shp2pgsql" in die postgis-Datenbank
importieren müßte, aber in "archves/install.txt", also einer anscheinend
veralteten Dokumentation sollte man das tun (was aber bei "ALTER TABLE" im
zweiten Schritt fehlschlägt). Im Wiki wird dieser Import nicht erwähnt, es
soll nur ein mit Shapefiles gefülltes world_boundaries-Verzeichnis
existieren.
Ist meine Karte deswegen blau?
Was auch komisch ist: Ich kann (blaue) PDF's generieren,
aber ./generate_image.py kann kein "mapnik"-objekt ansprechen, es wurde
offenbar nicht erzeugt:
Traceback (most recent call last):
File "./generate_image.py", line 41, in
if hasattr(mapnik,'mapnik_version') and mapnik.mapnik_version() >= 700:
NameError: name 'mapnik' is not defined
Aber Aufrufen von "mapnik_version()" geht in Python, und gibt korrekt "700"
zurück.
Was sagen die Kräcker dazu ("Cracks" auf deutsch)?
Jochen
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tag-Babelfisch
Hallo,
ich bin ja erst seit dem Erdbeben in Haiti in den OSM-Mailinglisten (ich lebe
da in der Nähe und brauchte dringend spezielle Karten, mittlerweile bin ich
aber nicht in Port-au-Prince hängengeblieben, sondern bei OSM), und war
erstaunt über die langen Diskussionen zum Thema "Tagging".
Claudius und Milo hatten mich schon über den Sinn von Tagging-Reichtum
aufgeklärt, und daß OSM viel mehr ist als nur *die* eine Karte die man kennt.
Und in der Tat bin ich angetan von der Schönheit der anderen "Produkte" und
beeindruckt vom Potential der OSM-Gemeinschaft.
Aber ich sehe auch das Problem, daß ohne Ordnung das Verhältnis
Signal/Rauschen ein Problem sein oder werden kann.
Tagging sehe ich im Grunde als Attribute, die wegen ihrer Kombinierbarkeit oft
eine einfache Datenstruktur darstellen, bestimmte Schlüssel ergeben also in
ihrer Kombination eine spezifische Bedeutung.
Vielleicht wäre eine Notation ähnlich wie man das von JSON oder YAML(.org)
kennt, eigentlich die native Darstellung dafür, aber das ist ein anderes
Thema.
Meine Idee ist "Tag-Babelfisch":
1.: OSM nach verwendeten Tagging-Kombinationen durchsuchen
2.: Beginnend bei den häufigsten Kombinationen, bedeutungsähnliche oder gar
redundante Kombinationen zuordnen ("1.0" für identisch, "0.8" für "ziemlich
ähnlich", "0.0" (default) für "total unterschiedlich).
3.: Auf dieser Basis Diskussionen zur Vereinfachung und Standardisierung des
Taggings führen
Das Endprodukt wäre eine Datenbank (lokal z.B. SQLite), am besten gleich mit
grafischen Symbolen.
Als Nebenprodukt wären die Programmierer der Editoren in der Erstellung und
Pflege eines solchen Kataloges entlastet, und bräuchten nur die Datenbank
einzubinden.
Als Mapper könnte man mit einem solchen Katalog wegen der "gleitenden
Assoziativität" einfacher zwischen möglichen Alternativen auswählen.
Systematisches Transformieren der OSM-Daten zur Vereinheitlichung des Taggings
zur homogeneren Darstellung wären möglich.
Vielleicht das wichtigste wäre ein vereinheitlichender und ordnender Effekt,
wenn eine solche Referenz existierte.
Was meint ihr dazu?
Danke fürs Lesen,
Jochen
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag-Babelfisch
Hi Lars,
danke erstmal fürs Antworten.
On Jue 04 Feb 2010, Lars Francke wrote:
> Hallo,
>
> > 1.: OSM nach verwendeten Tagging-Kombinationen durchsuchen
>
> dieser Teil ist ziemlich rechen-/zeit-/speicheraufwendig. In diesem
> Falle weiß ich ausnahmsweise wovon ich rede: osmdoc.com hatte die
> Funktion mal und die wird auch demnächst wiederkommen (hosting
> fehlt...). Ich rede hier aber nicht von wenigen Zeilen, die einfach in
> einer SQLite DB gespeichert werden sondern von hunderten von
> Millionen/Milliarden (je nachdem wie detailliert man das moechte)
> verschiedener Kombinationen und Zeilen.
Wow, osmdoc.com kannte ich noch gar nicht. Respekt!
Die temporären Daten werden groß sein bei der stochastischen Analyse, aber
irgendwo definiert man eben eine Grenze der Signifikanz und orientiert sich
schließlich beim Endprodukt der Tagging-Datenbank zum Verteilen an den
häufigsten paar tausend Tag-Kombinationen oder so.
Also zum Schluß hat man fast alle Information hinausgeworfen.
Von der Methodik her (ich bin jetzt kein Experte in Data-Mining) würde ich
nach Korrelationen suchen, also zunächst einmal semantische Kombinationen
identifizieren. Ich denke da praktisch an einen XML-Analysator für
planet.osm.
Als "gleichzeitig" gilt das Auftreten eines Ereignisses in derselben Node,
Relation, Way oder Changeset.
Sowohl Schlüsselname als auch Schlüsselwert sollten gleichberechtigt
unabhängig analysiert werden, am besten sollten sogar syntaktische
Trennzeichen wie ":", "|" oder ";" als solche interpretiert werden.
Auch das Ereignis des "XML parent" (Node, Relation, ...) sollte ausgewertet
werden (um zu erkennen, welche Tags z.B. nur in Ways auftreten (sollten)).
Es werden Einzelhäufigkeiten und Paarhäufigkeiten in der Auswertungsdatenbank
gespeichert, das werden zig Gigabyte werden. Alle Ereignisse werden als
Integerwerte codiert.
Ist planet.osm fertiggeparst, geht es an die Ermittlung von Korrelationen (da
müßte es doch auch einen Trick on-the-fly geben, aber evt. schmeißt man ja zu
früh Ergebnisse weg).
Dann geht es wohl los mit dem Ignorieren, da (n-1)^2/2
Korrelationskoeffizienten[1] ermittelt werden müßten. Ich nehme an, da nimmt
man die häufigsten 2 Millionen Wertepaare oder so. 2 Wochen Rechenzeit? Keine
Ahnung. Irgendwo als ge-"nice"-ter Rechenjob auf einem sich langweilenden
Server.
Von denen untersucht wiederum bei den maximal Korrellierenden, ob es weitere
hochkorrelierte Beziehungen gibt, also Suche nach Mehrfach-Koinzidenz
(maximal 4 nehme ich an).
Dann ist man schon fertig mit dem "Extrakt", und bricht nach 70 tausend oder
so in der Rangfolge ab.
Nun hat man (so hoffe ich) bedeutungsbehaftete Tag-Kombinationen isoliert, die
die Mapper miteinander in Beziehung setzen können.
Dazu bietet man ihnen auf einer Webseite ein Interface zu diesen Daten an.
Eine natürliche Kategorisierung erfolgt glaube ich schon durch die
Begrenztheit der Schlüsselnamen (oder irre ich mich da?).
Die Benutzer haben nun die Möglichkeit, Kombinationen als mehr oder
weniger "ähnlich" zu definieren. Vielleicht kann man das mit einem
Preisausschreiben kombinieren (12 Nexus-One, Nokia Nxxx oder Garmins, oder
Charity für Haiti, was weiß ich).
Diese paar tausend Notationen mit ihrer Ähnlichkeitsbeziehung und möglichen
Rendersymbolen werden dann in eine kleine Datenbank von 2MByte oder so
gepackt.
Je näher sich Tag-Kombinationen sind, desto eher hat man Kandidaten für (haha
Bots, nein.) zur Konsolidierung und neuen Brennstoff für noch längere Threads
für den verbalen Kampfsport, oder mit anderen Worten eine Diskussionsbasis,
und es werden nicht nur isolierte Einzel-Tags betrachtet wie bei Tagwatch,
sondern sozusagen "Objekte".
Man hat sozusagen da draußen nicht nur uns Daten-Typen, die mappen (kleines
Wortspielchen), sondern Tag-Datentypen, die mehr oder weniger als kongruent
gemappt werden.
Man muß da dann nicht unbedingt die Sense bei den redundanten Notationen
ansetzen, sondern gerade weil man ja nun weiß, daß bestimmte Notationen sehr
dicht beieinander liegen, können sie problemlos koexistieren.
Im Editor werden diese Tags dann aus der 2 MByte-Tag-Datenbank eingebunden.
Wegen der stetigen assoziativen Beziehung zu den Bedeutungen werden einem dann
Symbole mit Beschreibungen optisch auch entsprechend gruppiert zur Selektion
angeboten (am besten nicht in einer eindimensionalen Menüleiste, sondern auf
einer zweidimensionalen Verteilung von Elementen), am besten optional noch
mit Erläuterungstext über die Alternativen, so wie jetzt auf dem Wiki.
> > 2.: Beginnend bei den häufigsten Kombinationen, bedeutungsähnliche oder
> > gar redundante Kombinationen zuordnen ("1.0" für identisch, "0.8" für
> > "ziemlich ähnlich", "0.0" (default) für "total unterschiedlich).
>
> Hast Du dafür ein Beispiel?
Also das Widget das ich mir vorstelle, ist eine Wolke von Begriffen oder
Symbolen, bei denen Du das, was Dich interessiert, ins Zentrum klickst.
Da gabs doch diese assoziative Suchmaschi
Re: [Talk-de] Hilfestellung bei GPX-Datei
Hallo Jan, Erstmal die Unterschiede von Deiner Datei zu einem geläufigen GPX-Format wie von GPX-Babel: - Im Header gibt es kein "" oder "". - in gibt es kein - in gibt es kein oder Aber laut XML-Schema in http://www.topografix.com/GPX/1/1/gpx.xsd oder http://www.topografix.com/GPX/1/0/gpx.xsd sind diese Angaben auch nicht erforderlich. Also wenn ich mich nicht irre, ist Dein GPX-File standardkonform, und wird auch in meinem JOSM 2561 korrekt dargestellt. Grüße, Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenname kurz oder lang?
Hallo Martin, On Vie 05 Feb 2010, Martin Trautmann wrote: > Bei mir konvertiere ich erst mal alle Accents und Umlaute nach A, AE und > suche iterativ nach SS, SSS oder SS-S Nur mal zur Rückfrage: Wo konvertierst Du das? Doch nicht in OSM? Beim Bauen eines Suchindex, und der der Entgegennahme des Suchtextes, nehme ich an? Reguläre Ausdrücke sind nicht effizient in großen Datenbanken, aber es gibt Datenbank-Tabellentypen, die Volltext-Suche mit Operatoren wie NEAR, OR, NOT, AND unterstützen. Oft wächst dadurch das Indizieren die Datenbank-Größe um das Dreifache an. Ganz ohne Installation geht das mit SQLite und der Google-schen FTS3-Erweiterung dafür (FTS=fulltext search). Google verwendet SQLite+FTS3 für Volltextsuche bei einigen seiner Desktop-Produkte. Die Suchergebnisse kommen damit quasi instantan. SQLite mußte man früher explizit mit dieser FTS3-Option kompilieren. Also meine Empfehlung: Automatisch als OR-Ausdruck alternative Schreibweisen abfragen. Alternativ gibt es in vielen Datenbanken und Programmiersprachen wie PHP und Perl "soundex()"-Funktionen, auch in PostgreSQL und MySQL, bei denen nach ähnlicher Aussprache gesucht wird. Was ich nicht weiß ist, welche Phoneme durch soundex() abgedeckt werden. Nur meine dos centavos, Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planet-Extrakt D-A-CH
Hallo Frederik, ein schönes Optimierungsproblem (abgesehen vom Vergröbern bei den übergeordneten Grenzen). Ich versuchs erstmal ohne die "übergeordnete Grenze" mit verschiedenen iterativen Ansätzen[1], mal sehen, was am besten konvergiert. Also, Problem: Die Punktanzahl des umschreibenden Polynoms bei bestmöglicher Anpassung an das Ursprungs-Polynom minimieren. Als Indikator für "Güte" nehme ich die Relation: 1 - Flächendifferenz beider Polynome / Originalfläche denk ich mal. Bei 1=100% hat man exakte Übereinstimmung, alles andere liegt unterhalb oder wird sogar negativ. Es gibt dann wohl einen Parameter, der geschmacks- oder situationsabhängig ist, ich nehme an, das ist genau diese Güte. Dann mach ich wohl am besten ein grafisches Programm mit Güte-Schieberegler, in das man Polygone einlesen[2] und gucken kann, wie die verschiedenen Güten im Zoom aussehen. Dann hast Du irgendwann den richtigen Kompromiß gefunden, der dann wohl für alle anderen Polygone auch so verwendet werden kann. Das einzige was jetzt zu fragen bleibt, ist: Was mache ich mit Mehrfach-Polygonen wie z.B. Faröer? Wenn man das in ein Polygon zusammenfaßt, was macht man dann z.B. mit Frankreich+Martinique+Korsika? Vielleicht darf das Polygon ja nur eine Grenze überschreiten, das wäre eine Möglichkeit. Dann wäre Korsika auf der Frankreich-Karte, aber nicht Martinique. Ich erstelle das für Linux und Windows, Mac hab ich nicht greifbar. Jochen On Vie 05 Feb 2010, Frederik Ramm wrote: > 6. Vereinfache das Polygon so, dass es maximal 500 Punkte hat und dass > die vereinfachte Version vollstaendig ausserhalb der Originalversion > liegt. Verwende diejenige aller moeglichen Vereinfachungen, die am > ehesten an der Originalflaeche liegt. Ausnahme: Dort, wo die Umrandung > des Polygons entweder eine Kuestenlinie ist oder mit der Umrandung des > hierarchisch darueberliegenden Polygons zusammenfaellt (also z.B. dort, > wo NRW an Belgien grenzt und die NRW-Grenze daher mit der D-Grenze > zusammenfaellt), darf das Grenzpolygon grosszuegig vereinfacht sein. [1] Newtonsches Gradientenverfahren, Simulated Annealing und "Threshold Accepting" fallen mir da spontan ein. [2] OSM XML, ASCII-Koordinatenzeilen mit Leerzeile für Polygon-Ende, oder GPX als Eingabeformat ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation wird nicht angezeigt
Moin Tirkon, On Sáb 06 Feb 2010, Tirkon wrote: > http://www.openstreetmap.org/?relation=62355 > > Zunächst würde mich intessieren, ob bei Euch die Relation dargestellt > wird. Natürlich interessiert mich ferner, was die Fehlerursache sein > könnte. Linux (Debian stable, "Lenny"): Firefox-3.6: geht Konqueror-3.5.10: geht nicht (Meldung (hab ich jetzt schnell aus dem Spanischen übersetzt): "Diese Form des Vektor-Renderns wird nicht unterstützt, verwenden Sie stattdessen bitte SVG, Canvas und .") Opera-9.63: geht. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation wird nicht angezeigt
Moin nochmal, On Sáb 06 Feb 2010, Tirkon wrote: > >Meldung: Unbekannter Fehler. > >Zeile: 483 > >Zeichen: 208 > >Code: 0 > >URI: http://www.openstreetmap.org/openlayers/OpenLayers.js?1251388304 Geht nicht auf Windows7. Identische Fehlermeldung auf Windows7 und IE 8, bei "aktiviertem Schutzmodus". Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Moin Loide (sowie sehr geehrte Damen und Herren), eigentlich gibt es das Format ja schon, das Rad braucht man nicht erfinden, würde ich sagen, und heißt JSON (JavaScript Object Notation). http://www.json.org/example.html (oben z.B.) Das wird u.a. bei AJAX- Web-Applikationen ständig verwendet. Das Format kann man "umgießen", also in einen einzelnen Text-String quetschen (dann wäre es sogar kompatibel mit der v0.6 API von OSM), oder automatisch eingerückt darstellen, wie es beliebt. Es bietet hierarchische Struktur, Listen/ Arrays, Hashes, verschachtelte Datenstrukturen, also eigentlich alles, was man braucht und als Skript-Programmierer schon seit Jahrzehnten kennt. Schnittstellen/ Libraries zu allen gängigen Programmiersprachen sind vorhanden (C/C++, Java, Python, PHP, Flash ActionScript, Perl, etc). Was man dabei zunächst verlöre, wenn die Datenbank damit nicht umgehen kann, wäre die 1:1-Beziehung zwischen k,v-Werten und Darstellung. Aber zum Glück gibt es ja PostgreSQL, dafür gibt es sicher irgendwo eine native Umsetzung? Wenn nicht, kann man das mit einer klassischen rekursiven Datenstruktur mit ID-Pointern (wie bei Dateisystem-Inoden) auch mit jeder Wald- und Wiesen-Datenbank definieren. Ob expliziter Zugriff auf jedes Unter-Element per Datenbank performant ist, ist eine andere Frage. Aber vielleicht wäre so eine Umsetzung auch die Lösung für viele Spezial-Abfragen, bei denen man heute erst einmal einen eigenen Tag-Parser braucht, oder sehr viele Ergebnisse verwirft, weil man nicht nach einem spezifischen Namensraum fragen kann. Aber definitiv wäre das der systematischere Ansatz. Meine 2 inflationären Centavos aus der 26°C warmen DomRep, Jochen On Lun 08 Feb 2010, Johannes Huesing wrote: > Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die > Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig > verstanden habe) gegenüber räumlicher Ordnung und Relationen einen > wesentlichen Vorteil bietet. Wenn die Editorschnittstelle davor das > Entscheidende ist, ist das Datenmodell dahonter doch ohnehin zweitrangig > (zumindest wenn es zu wenig anfängerfreundlich erscheint). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankschema
Hallo Stefan, On Vie 12 Feb 2010, p3p wrote: > gibt es irgendwo ein Datenbankschema für die von osm2pgsql verwendete > Datenbank? PostGIS würde ich auch gern besser verstehen. Das Format ist wohl dermaßen optimiert, daß man z.B. von Wege-Knoten direkt nicht mehr viel sieht, das wird alles in einen ID-Sequenz-BLOB gepackt. Ich habe jetzt ein Skript geschrieben, daß ein intuitiv verständliches Datenbank-Schema erzeugt. Keine Ahnung ob Du dafür Verwendung hast. Das ist natürlich Größenordnungen von der Performanz von PostGIS entfernt. Meinetwegen können wir uns gerne kurzschließen. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankschema
Danke Frederik! pgadmin3 verwende ich zum Herumstreunen in PostgreSQL, und zum Kennenlernen der 600+ Geo-Funktionen in PostGIS hilft in dem Zusammenhang ein bißchen, postgis_comments.sql aus der postgis-Distribution in der Datenbank auszuführen, für rudimentäre Orientierung. Damit bei mir das von Stefan Gewünschte funktioniert: select name, st_astext(st_transform(way,4326)) from planet_osm_point where place='city'; mußte ich den folgenden Eintrag in der Datenbank hinzufügen (eine Zeile): INSERT into spatial_ref_sys (srid, auth_name, auth_srid, proj4text, srtext) values ( 900913, 'spatialreference.org', 900913, '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +wktext +no_defs', 'PROJCS["unnamed",GEOGCS["unnamed ellipse",DATUM["unknown",SPHEROID["unnamed",6378137,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Mercator_2SP"],PARAMETER["standard_parallel_1",0],PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1],EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +wktext +no_defs"]]'); Bzw. Quelle: http://geodjango-basic-apps.googlecode.com/svn/trunk/projects/geographic_admin/utilities/postgis_google_proj.sql Vorher kam bei mir die Meldung: "Cannot find SRID (900913) in spatial_ref_sys" Ergebnis: name| st_astext +- Port-de-Paix | POINT(-72.8307609 19.9399753) Gonaives | POINT(-72.6884336 19.4460597) | POINT(-72.4535965 18.5442413) Carrefour | POINT(-72.4092468 18.534557) Port-au-Prince | POINT(-72.3393295 18.549274) Cité Soleil| POINT(-72.335601499 18.5782768) Pétionville| POINT(-72.2860209 18.5132181) Delmas | POINT(-72.2780417 18.5445886) Cap-Haïtien| POINT(-72.2008068 19.7595237) ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankschema
Hallo Sven, On Vie 12 Feb 2010, Sven Geggus wrote: > Frederik Ramm wrote: > > Ein Datenbankschema, das noch aehnlicher dem "echten" OSM-Schema ist und > > in dem sich alle Tags in eigenen Tabellen befinden, bekommst Du, wenn Du > > statt mit osm2pgsql die Daten mit osmosis in eine PostGIS (oder auch > > MySQL) einliest. Irgendwie läuft bei mir auch kein Osmosis (0.33-bin, nicht selbst kompiliert), trotz neuen Oracle-Javas (oder vielleicht deswegen? ;-) ). Klasse Klassen, früher hab ich in der Klasse gefehlt, und heute fehlen sie bei mir? > Weil ich die Tage gerade wieder drüber gestolpert bin. Ein fertiges > script, das OSM Objekte in Postgres hstore überführt gibt es > offensichtlich immer nicht nicht. Um POI-Karten mit selten > verwendeten Spezialtags zu basteln wäre sowas cool. Alle > Getränkehändler mit club-mate um nur mal ein Beispiel zu nennen. So eine Karte für dieses getränkhaltige Erfrischungs-Koffein hab ich schon mal irgendwo gesehen, hihi ;-) > Wenn man da alle POI Tags in ein hstore reinsteckt braucht man nicht > für jedes Exotenzeug eine extra Tabelle. > > Das osmosis Schema bildet ja den hstore quasi durch eine > osm-id,key,value tabelle nach. Ich kann leider kein Java dürfte > vermutlich einfach sein sowas da einzubauen. Ja, wa? Könn' wa beide kein Java? Das Schlüssel-Gedöns müßte man doch auch schnell Datenbank-intern nach hstore gehievt bekommen. Schau mer mal. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankschema
Hallo nochmal, On Vie 12 Feb 2010, Jochen Plumeyer wrote: > > On Vie 12 Feb 2010, Sven Geggus wrote: > > Alle Getränkehändler mit club-mate um nur mal ein Beispiel zu nennen. > > So eine Karte für dieses getränkhaltige Erfrischungs-Koffein hab ich schon > mal irgendwo gesehen, hihi ;-) Es gibt sogar (mindestens) *zwei* Club-Mate Karten: http://hackerbrause.de/2009/07/kartographie-der-mate-here-be-dragons-hackerbrause/ Die erste funktioniert mit OSM und verwendet ein tag "club-mate=yes". Wie gut, daß all die zurückhaltend vorgehenden Manneskraft-Medikamente- oder Armbanduhren-Verkäufer davon noch keinen Wind bekommen haben... Oder haben sie? Droht uns bald Geo-Spam? Oder gibt's sogar schon Antispam-Bots dagegen? Bott bewahre. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Hallo Pascal, On Lun 15 Feb 2010, Pascal Neis wrote: > Bei mir auf dem Mac gibt es eigentlich keine Probleme > und wie Sven geschrieben hat auf Linux auch nicht. > Damit gibt es wohl leider nur Probleme mit Windows ... Negativ, Firefox-3.6/Linux brachte mich gestern nacht auf eine Spam-Seite, und jetzt gerade sehe ich einen ewigen Redirect. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] injooosm
Hallo Christian,
On Lun 15 Feb 2010, Christian Knorr wrote:
> habe eben 0.4.5 veröffentlicht. Nun ist es endlich mit dem IE8 anzeigbar.
> Kann mir jemand was zu anderen Browsern sagen?
SeaMonkey-2.0.2, Konqueror-3.5.10, Opera-9.63, Firefox-3.6 ohne Probleme auf
Linux Debian 5.0.4 ("Lenny"/ "stable").
Kannst Du auch ein PlugIn für http://cmsmadesimple.org schreiben, wo Du gerade
dabei bist? ;-)
Jochen
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG probleme - an die checker!
Moin Gary, On Mar 23 Feb 2010, Walter Nordmann wrote: > und jetzt auch die fussbälle auf grünem grund - musste die grafik auch > runterladen und den pfad im svg ändern, dann gings. Dito, bei mir sieht's nach dieser Änderung in Inkscape-0.47 auch ok aus, es gibt drei Rechtecke, das blaue Rechteck ist vom PNG-gefüllten kongruenten Rechteck rechts unten überdeckt, von den drei sind also nur zwei sichtbar. Jochen Patch: --- /tmp/web.svg2010-02-23 17:44:25.0 -0400 +++ web.svg 2010-02-23 20:40:10.0 -0400 @@ -4,11 +4,11 @@ - + - + ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG probleme - PRÄZISIERUNG II
Moin Gerhard, On Mié 24 Feb 2010, Gary G: wrote: > so, nun ist es raus. der evince ist der böse. > > - inkscape direkt zeigt korrekt an. > - inkscape -e nach PNG geht auch. > - inkscape -A nach PDF mit ACROBAT ansehen geht. > - inkscape -A nach PDF mit EVINCE GEHT NICHT. > > mal sehen, ob es einen anderen PDF reader für linux gibt... Bei mir (Debian stable) zeigt evince-2.22.2 das PDF an: http://plumeyer.org/delete-weekly/web.pdf GhostView (gv) ging nicht kpdf stürzte ab nach Speichermangel (hab gerade osm2pgsql planet.osm am Laufen). Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Routing auf WinCE
Hallo, On Vie 26 Feb 2010, Frederik Ramm wrote: > denn ich habe selbstverstaendlich in meiner Jugend auch Routing-Programme > geschrieben ;-) Ist das nicht theoretisch ein NP-hartes Problem, das uns nur den Gefallen tut, sich in der praktischen Realität doch fast immer gutmütig zu verhalten (wegen gleichmäßiger Vernetzung)? Schätze ich jetzt einfach mal, so ungefähr (mittlere Wegabzweigungsanzahl)^Weganzahl? Also exponentielles Verhalten, kein polynomiales. Ich hab mich auch gewundert, daß da die brandaktuelle Forschung immer noch mehr aus den Algorithmen herauskitzelt... Lachend ins Wochenend, :-) Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing-Workshop am Freitag auf der FOSSGIS
Hallo, On Mar 02 Mar 2010, Frederik Ramm wrote: > Kai Krueger wrote: > > Insofern meine Frage, wird es Videoaufzeichnungen der Workshops geben? > > Fragten andere auch schon; soweit ich weiss, gibt es keine, weil niemand > die Arbeit machen kann oder will. Wie wär's mit MP3-Recorder mitlaufen lassen bzw. Audio? Das macht praktisch keine Arbeit, und muß ja auch keine tolle Qualität haben. So nach dem Motto "FossGIS broadcasting services proudly presents:" Ich mein ja nur. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Gewinnt Linux New Media Award
On Jue 04 Mar 2010, Florian Lohoff wrote: > Wir haben es auf der FOSSGIS Live beobachtet - Der Applaus fuer deinen > Auftritt haette eigentlich in Hannover hoerbar sein muessen ;) Nächstes Jahr kommt der BRAVO-Starschnitt mit Frederik Ramm! ;-) Obwohl, Teenie-Gekreische, will man das wirklich? Dr. Sommer löst Mapping-Probleme... Herzlichen Glückwunsch!!! :-) Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
