[OSM-talk] user comment to improve mkgmap [Fwd: OSM on Gramin for Metro Manila, Philippines}
Hi, One GPS user sent me his comments on my OSM Philippines Garmin maps [http://esambale.wikispaces.com/osmphil_gramin]. It could probably improve the mkgmap. - no poi nor city index - severely jagged lines (i know it comes from your compiler...), I had a go at the osm compiler; it's fast! - why a transparent map? sorry-osm compiler. on some units you can't turn off the base map so your map will interfere with garmins base map. - size of 3013 is too high for older garmin units, they won't be able to redraw fast enough - automate installation process to GPS unit. cheers, maning Forwarded Message From: maning sambale [EMAIL PROTECTED] To: talk@openstreetmap.org Subject: OSM on Gramin for Metro Manila, Philippines Date: Thu, 3 Jan 2008 16:14:35 +0800 Hi, I intend to regularly maintain img file for Garmin GPS for my mapping area (Metro Manila Philippines) [http://www.openstreetmap.org/index.html?lat=14.594717284692324lon=121.03235961646361] I created a page download for this [http://esambale.wikispaces.com/osmphil_gramin]. As I currently don't have a Garmin unit now, can somebody please get the files and test if it works on your Garmin GPS. The first file can be found here: [http://esambale.wikispaces.com/space/showimage/20080102.zip] If some Garmin users in the Philippines can use these maps, maybe they can be encouraged to contribute. cheers, maning ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Adding vmap0 road data to OSM
80n wrote: There's some anecdotal evidence that seeding an area with some data encourages local contributors. If this is actually true then loading vmap0 would be a good thing. Seeding with some 7000 kilometers of travel data and the rough locations of about 100 major cities worked for Turkey. By now we have a lot of people who map the bigger cities. Before the seeding, there were only three people who uploaded anything at all in that area. I think it would be a good thing to load vmap0 data for any area where there is currently no data at all. The idea that seeding roads that have no other data nearby (say, 100 kilometers or so) sounds really interesting, that way, we would at least have a rough skeleton of the road network. Regards, Hakan -- The Key To Immortality Is First Living A Life Worth Remembering. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Adding vmap0 road data to OSM
On Jan 6, 2008 10:31 AM, Igor Brejc [EMAIL PROTECTED] wrote: Karl Newman wrote: I'll wholeheartedly concur here. I looked at openstreetmap early in 2007 and concluded it wasn't quite ready for primetime, because there was almost no mapping done in the US. I came back a few months later and noticed the TIGER data being added and decided it was worth my time after all. If you can get even the major road networks done, it's a key starting point that can draw people in. Karl Heh, one anectodal evidence of the opposite kind: when I saw 4 months ago the area where I live was almost completely blank, it gave me an extra motive to get involved - I would be the first person to map the area :). Cheers, Igor Well, my perspective was as a data consumer. I was looking for data which could be converted to routable Garmin GPS maps... I've done a little bit of mapping, mostly along my commute route, and I try to remember to take my GPS along any time we're going someplace I haven't collected traces for yet (my wife rolls her eyes), but so far I've been putting more effort into programming and guiding tag proposals so that they're compatible with the GPS map requirements. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Adding vmap0 road data to OSM
On Jan 6, 2008 11:31 AM, Igor Brejc [EMAIL PROTECTED] wrote: Well, my perspective was as a data consumer. I was looking for data which could be converted to routable Garmin GPS maps... I've done a little bit of mapping, mostly along my commute route, and I try to remember to take my GPS along any time we're going someplace I haven't collected traces for yet (my wife rolls her eyes), but so far I've been putting more effort into programming and guiding tag proposals so that they're compatible with the GPS map requirements. Karl Pretty much the same with me. I am especially interested in covering hiking trails because even commercial GPS maps for my area lack a lot of data. Unfortunately, with winter in our parts, not much can be done at the moment. As for roads, I covered as much as I could at the beginning, trying different routes to work, but I more or less exhausted the possible routes - it's not a big town :). So now I have time to concentrate on my other hobby - developing map rendering engines. Igor Yes, that was the same with me--I was frustrated at the poor trail coverage and especially lack of routable trails on most map products (the only Garmin map that has it is the National Parks 24k topo, but coverage is limited to US national parks only. OpenStreetMap gives me the possibility to have a unified routable road + trail map on my GPS. I'm in California, so we don't generally worry about snow so much (except if you're in the mountains, especially this weekend). Floods, on the other hand, are currently a more likely obstacle... Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Adding vmap0 road data to OSM
Karl Newman wrote: On Jan 6, 2008 11:31 AM, Igor Brejc [EMAIL PROTECTED] wrote: Well, my perspective was as a data consumer. I was looking for data which could be converted to routable Garmin GPS maps... I've done a little bit of mapping, mostly along my commute route, and I try to remember to take my GPS along any time we're going someplace I haven't collected traces for yet (my wife rolls her eyes), but so far I've been putting more effort into programming and guiding tag proposals so that they're compatible with the GPS map requirements. Karl Pretty much the same with me. I am especially interested in covering hiking trails because even commercial GPS maps for my area lack a lot of data. Unfortunately, with winter in our parts, not much can be done at the moment. As for roads, I covered as much as I could at the beginning, trying different routes to work, but I more or less exhausted the possible routes - it's not a big town :). So now I have time to concentrate on my other hobby - developing map rendering engines. Igor Yes, that was the same with me--I was frustrated at the poor trail coverage and especially lack of routable trails on most map products (the only Garmin map that has it is the National Parks 24k topo, but coverage is limited to US national parks only. OpenStreetMap gives me the possibility to have a unified routable road + trail map on my GPS. I'm in California, so we don't generally worry about snow so much (except if you're in the mountains, especially this weekend). Floods, on the other hand, are currently a more likely obstacle... Karl Or maybe runaway tigers? :) Igor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [Talk-GB] Southwest Surrey Mapping Party - signup on wiki
Nick Whitelegg wrote: No venues as yet. Jonathan (Bennett) - since you live in the area, do you know anywhere suitable in Guildford (e.g. wi-fi access?) The pub we ended up in at the last Guildford meet-up, the Guildford Tup (http://www.openstreetmap.org/?lat=51.23744lon=-0.56999zoom=16layers=B0FT) has free Wi-Fi I think, but it's the wrong side of the town centre for the area we'll be mapping. I'll see if there's anywhere in Godalming, maybe, that has Wi-Fi. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] user comment to improve mkgmap [Fwd: OSM on Gramin for Metro Manila, Philippines}
On Jan 6, 2008 1:49 PM, Steve Ratcliffe [EMAIL PROTECTED] wrote: Hi Thanks for sending these comments on. - no poi nor city index That's right, and I am working on on adding cities at the moment. I'm not sure how long it will take or what it takes to make them searchable, but it seems to be possible with what is publicly known about the format. - severely jagged lines (i know it comes from your compiler...), I had a go at the osm compiler; it's fast! Which version did you use to create the map? If was 388, then you find that that the latest version (506 or above) is very much better in that respect. - why a transparent map? sorry-osm compiler. on some units you can't turn off the base map so your map will interfere with garmins base map. It is not intentionally transparent, and indeed is not transparent on my GPSr. I'll try adding background polygons to the main maps, some units may need them. - size of 3013 is too high for older garmin units, they won't be able to redraw fast enough It might be possible to make this configurable to some extent. However mkgmap does not have one 'size' - the areas vary in size according to how much detail there is on them and so looking at the largest size is deceptive. On the other hand the newer version of mkgmap is better able keep the divisions smaller where there are large elements, so it may be better here too. - automate installation process to GPS unit. This is outside the scope of mkgmap, although I would be happy to include or publicize solutions developed by others. ..Steve For that last point, I think the new version of sendmap (www.cgpsmapper.com) can create self-contained exe files which will download the map set to an attached GPS. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk-nl] Nogmaals: OpenStreetMap nieuwjaarsborrel
Ha allen, Ik heb nu ook een blogpostje gemaakt over de nieuwjaarsborrel. http://www.openstreetmap.nl/archives/53-OpenStreetMap-Nieuwjaarsborrel.html Extra info daarin is dat het budget momenteel nul is en dat iedereen daarom zijn eigen drankjes betaalt. Het lijkt me trouwens leuk om ook wat externe mensen uit te nodigen. Iemand nog ideeën? Ik heb in elk geval al een mailtje gedropt bij de mensen van Bliin. Schroom niet om mensen uit te nodigen! Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Nieuwjaarsborrel: 13 januari 14:00
Martijn van Exel wrote: Ha, Op zondag 13 januari vindt de OpenStreetMap Nederland Nieuwjaarsborrel plaats! Iedereen die OpenStreetMap Nederland een warm hart toedraagt, als actieve vrijwilliger of hoe dan ook, is van harte welkom vanaf 14:00 in café Dwaze Zaken in Amsterdam voor een dronk op een geweldig jaar voor OSM Nederland! Laat even weten of je komt. Ik ben er ook bij. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [Talk-de] Landuse verdeckt Fluss
Hallo Paul, also ich kann den Fluss sehen ... Viele Grüße Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zusammenfassung vom Treffen auf dem 24C3
Frederik Ramm schrieb: Ich guck mir das gern mal an... weiss jemand zufaellig die EPSG-Codes fuer die verschiedenen GK-Varianten, Ja, unser WIKI: http://wiki.openstreetmap.org/index.php/Gau%C3%9F-Kr%C3%BCger Bye Frederik -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zusammenfassung vom Treffen auf dem 24C3
Sven Geggus schrieb: Hallo Fred, ... Das ganze ist furchtbar langsam, weil der mapserver das immer on-the fly von GK in lat/long konvertieren muss. Stell Dich drauf ein, dass Du etwa eine Minute oder so warten musst bis ein Bild kommt. Gruss Sven Ich habe da andere Erfahrungen. Der (UMN-) Mapserver ist so ziemlich das schnellste Programm für diesen Zweck und die Umprojektion ist eigentlich auch kein Problem. Es gehören allerdings ein paar Kniffe dazu, das Handling großer Luftbilder performant hinzubekommen. Die liegen meist im TIFF-Format vor und sind 1x1 oder 2x2 Kilometer groß. Das sind dann Dateien von ca. 80 Megabyte je Kachel. Wenn man dann auf eine Ecke trifft muss der Mapserver 4 dieser Dateien laden, verkleinern daraus den benötigten Bereich ausschneiden (4x) und zu einem neuen Bild zusammen fügen. Das wird dann zum Massenproblem. Abhilfe: 1.) Farbtiefe des Bildes reduzieren. Datei schrumpft auf 1/3 ohne dass man den Unterschied sieht. 2.) mit gdaladdo eine interne Vorschau (Maßstabspyramide 2-4-8-16) in das Bild einbauen. So braucht meist nur der Datei-Anfang ausgelesen werden. Der ist dann schon verkleinert. 3.) mit gdaltindex einen Tile-Index bilden um die einzelnen Kacheln effektiv zu finden. Die Antworten (WMS GetMap-Request) liegen dann im Sekundenbereich. -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Moin, Mein Programm zum Erstellen von OSM-Dateien für Küstenlinien kann jetzt geschlossene Polygone untersuchen, ihre Richtung bestimmen und - falls erforderlich - diese so umkehren, dass sie gegen den Uhrzeigersinn verlaufen, wie es sich für eine Insel gehört. Siehe http://www.lenz-online.de/divers/osm Ich hab nicht ganz verstanden was der Sin dieses Programms ist. Die Küstenlinien wurden ja grösstenteils bereits Importiert und dort korrigiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Hallo, Raphael Studer wrote: Ich hab nicht ganz verstanden was der Sin dieses Programms ist. Die Küstenlinien wurden ja grösstenteils bereits Importiert und dort korrigiert. Wurden sie eben nicht - Europa ist zwar weitgehend vollstaendig (selbst da fehlen in Skandinavien glaub ich noch einige Sachen), aber viele andere Küstenlinien weltweit sind noch nicht importiert. Das ist immer Handarbeit, und Pauls Programm macht diese Handarbeit leichter, besonders fuer Leute, die nicht mal eben so ein Perl-Skript schreiben, das ihnen irgendwas sortiert oder umdreht ,-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zusammenfassung vom Treffen auf dem 24C3
Frank Jäger [EMAIL PROTECTED] wrote: Es gehören allerdings ein paar Kniffe dazu, das Handling großer Luftbilder performant hinzubekommen. Ähm ja, das hab ich auch gemerkt. Abhilfe: 1.) Farbtiefe des Bildes reduzieren. Datei schrumpft auf 1/3 ohne dass man den Unterschied sieht. 2.) mit gdaladdo eine interne Vorschau (Maßstabspyramide 2-4-8-16) in das Bild einbauen. So braucht meist nur der Datei-Anfang ausgelesen werden. Der ist dann schon verkleinert. 3.) mit gdaltindex einen Tile-Index bilden um die einzelnen Kacheln effektiv zu finden. Das Problem, dass ich dabei hatte ist dass der Datenbestand durch diese Maßnahmen riesig wird, weil die einzelnen Kacheln unglaublich viel größer werden. Ich habe derzeit jpg-Bilder mit ca. 7MByte Größe. Mehr als das 4-5 fache dieser Größe möchte ich eigentlich nicht spendieren. Du darfst gerne mal ein kurzes Howto schreiben (am besten ins Wiki) wie man aus einer größeren Menge solcher GK-Kacheln im jpg Format etwas performantes für den mapserver produziert, ohne dass man nennenswerte Abstriche bei der Farbtiefe und Bildgröße einerseits machen muss und die Dateigrößen der Ergebnisbilder andererseits nicht ins unendliche steigen. Gruss Sven -- Whenever there is a conflict between human rights and property rights, human rights must prevail. (Abraham Lincoln) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Germany Roads Tagging II
Hallo, Man könnte die ref ergänzen, also wenn das K fehlt ein (K) einfügen also für die Augsburger Kreisstraße (K)A9 Man könnte sogar weiter gehen und bei den Kreisstraßen mit K den Landkreis angeben also für eine K9 hier in Aachen K(AC)9. So könnte man dann die verschiedenen K9 unterscheiden. Bei Landesstraßen könnte man das Bundesland mitangeben. Ob man dafür das bisherige ref nimmt oder ein neues ist dann Geschmackssache Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Ich hab nicht ganz verstanden was der Sin dieses Programms ist. Die Küstenlinien wurden ja grösstenteils bereits Importiert und dort korrigiert. Wurden sie eben nicht - Europa ist zwar weitgehend vollstaendig (selbst da fehlen in Skandinavien glaub ich noch einige Sachen), aber viele andere Küstenlinien weltweit sind noch nicht importiert. Das ist immer Handarbeit, und Pauls Programm macht diese Handarbeit leichter, besonders fuer Leute, die nicht mal eben so ein Perl-Skript schreiben, das ihnen irgendwas sortiert oder umdreht ,-) Gibts denn keinen offiziellen Küstenimportiertask ähnlich dem TIGER Ding? Eine praktische erweiterung für Pauls script wär, wenn die kleinen Seen (4-10 Nodes auf dem Festland) die manchmal generiert werden, gleich als solche getaggt würden. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zusammenfassung vom Treffen auf dem 24C3
Sven Geggus schrieb: Frank Jäger [EMAIL PROTECTED] wrote: Es gehören allerdings ein paar Kniffe dazu, das Handling großer Luftbilder performant hinzubekommen. Ähm ja, das hab ich auch gemerkt. Abhilfe: 1.) Farbtiefe des Bildes reduzieren. Datei schrumpft auf 1/3 ohne dass man den Unterschied sieht. 2.) mit gdaladdo eine interne Vorschau (Maßstabspyramide 2-4-8-16) in das Bild einbauen. So braucht meist nur der Datei-Anfang ausgelesen werden. Der ist dann schon verkleinert. 3.) mit gdaltindex einen Tile-Index bilden um die einzelnen Kacheln effektiv zu finden. Das Problem, dass ich dabei hatte ist dass der Datenbestand durch diese Maßnahmen riesig wird, weil die einzelnen Kacheln unglaublich viel größer werden. Meine Erfahrungen beschränken sich auf Ausgangsdaten im Format TIFF. Da gilt: Ausgang: 180 MByte je Bild Schritt 1: runter auf 60 MByte Dateigröße Schritt 2: wider rauf auf 80 MByte weil die verkleinerten Vorschauen dazu kommen. Insgesamt hat man nachher aber viel *weniger* Speicherbedarf. Ich habe derzeit jpg-Bilder mit ca. 7MByte Größe. Mehr als das 4-5 fache dieser Größe möchte ich eigentlich nicht spendieren. Du darfst gerne mal ein kurzes Howto schreiben (am besten ins Wiki) wie man aus einer größeren Menge solcher GK-Kacheln im jpg Format etwas performantes für den mapserver produziert, ohne dass man nennenswerte Abstriche bei der Farbtiefe Keiner braucht 16 Millionen Farben in einer Karte. 256 Farben reichen. Man sieht den Unterschied kaum. und Bildgröße Die bleibt erhalten einerseits machen muss und die Dateigrößen der Ergebnisbilder andererseits nicht ins unendliche steigen. Nein, die Optimierung liegt in der Verkleinerung. Gruss Sven Bis wir ein Howto haben: Google-Suche mit gdaladdo orthofotos zeigt u.a. http://mapserver.gis.umn.edu/community/conferences/MUM3/present/session2/hodgsonppt und ein paar andere Tipps. -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Hallo, Gibts denn keinen offiziellen Küstenimportiertask ähnlich dem TIGER Ding? Offiziell gibts sowieso gar nix ;-) die TIGER-Leute machen halt import first, fix stuff later, und bei den Kuestenlinien heisst es eher schnappt Euch einen Teil, der Euch interessiert, und macht den Import dann selbst - so ist ein groesseres Mass an menschlicher Kontrolle eingebaut, was angesichts der Datenqualitaet gar nicht so doof ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Besenwirtschaft/Strau?wirtschaft/Heckenwirtschaft/...
On Sonntag 06 Januar 2008, Michael Bergbauer wrote: On Sun Jan 06, 2008 at 12:2610AM +0100, Joerg Ostertag (OSM Munich/Germany) wrote: Ich gehe davon aus, dass in 90% aller Fälle jemand der in der Nähe wohnt oder öfter bei dem Wirt ist und einer der bis dahin 200.000 OSM Aktivisten das korrigiert, bevor du es selber machen kannst. So geht es mir bisher schon recht oft bei schon existierenden Sachen, die sich geändert haben. Bis ich am Abend dazu kommen würde das in OSM einzutragen ist es schon erledigt. Aber ich denke, das kommt im Moment daher, dass auch nur die Gegenden erfasst werden wo jemand in der Naehe wohnt. Wie sieht es aus mit Gegenden aus, die jetzt noch nicht gemapped sind und die sich jemand im naechsten Urlaub vornimmt? Auch da hab ich bei unserem momentanen User-Wachstum (10% pro Woche) nicht dir großen Bedenken. du musst einfach ein wenig Geduld haben und dann wird es für fast eden Fleck jemanden geben, der dort Ortskundig ist und sehr schnell alle Änderungen einpflegt. -- Jörg (Germany, Munich) http://www.ostertag.name/ irc://irc.oftc.net/#osm (sometimes) Tel.: 089/420950304 (VOIP: Only ringing while at home at the PC) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Parkplatz
Hallo, ich habe gestern schon mein Problem im Forum - http://forum.openstreetmap.org/viewtopic.php?id=385 - geschildert. Ich bin momentan dabei in Göttingen weiter Inhalte zu einzupflegen und zu korrigieren. Dabei ist mir unter anderem ein Parkplatz über den Weg gelaufen siehe: http://www.openstreetmap.org/?lat=51.52882lon=9.88166zoom=17layers=0BFT Da war ein User sehr fleißig und hat jede Parkplatz Linie digitalisiert. Ich würde es jedoch wie in http://wiki.openstreetmap.org/index.php/Mapping/Features/Parking beschrieben handhaben und eine Fläche digitalisieren mit amenity=parking und einen node mit dem Tag in die Mitte pflanzen. Meine Frage ist jetzt ob ich die bereits digitalisierten Wege raushauen soll und nur noch einen weg mit highway=service darüber legen soll. Zumal viele der Wege nicht miteinander verbunden sind, was aber eine generelles Göttinger Problem ist. Es gibt viele Wege aber häufig nicht verbunden, somit nicht routingfähig. Ich hätte nun gerne einen kleinen Ratschlag wie ich diesen Parkplatz handhaben soll, da ich recht neu hier bin. Werde mich schon mal ransetzen und das so editieren wie ich es für korrekt halte, damit ich bei einer Antwort gleich hochladen kann. Vielen Dank schon mal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplatz
Moin On Sunday 06 January 2008 15:14:57 Patzi wrote: Da war ein User sehr fleißig und hat jede Parkplatz Linie digitalisiert. Ich würde es jedoch wie in http://wiki.openstreetmap.org/index.php/Mapping/Features/Parking beschrieben handhaben und eine Fläche digitalisieren mit amenity=parking und einen node mit dem Tag in die Mitte pflanzen. Was die .../Parking Seite ebschreibt, ist im grunde das selbe, was der User in Göttingen schon gemacht hat. Lediglich eine Area mit amenity=parking die den gesammten Bereich gelb einfärbt fehlt noch. Zudem wird derzeit das highway=service dicker dargestellt als früher, weswegen solche Parkplätze oft etwas merkwürdig aussehen. Dennoch finde ich, das es sinnvoller ist jeden Weg einzuzeichnen den ein Autofahrer nehmen könnte. oftmals sind es ja auchnoch oneway wege auf einem Parkplatz. Es gibt viele Wege aber häufig nicht verbunden, somit nicht routingfähig. Die verbindungen würde ich dann auch mit korrigieren, damit man somit auf einen bestimmten bereich des Parkplatzes routen kann. (Wer weiß, vielleicht kann man irgendwnan per Satellit freie Parkplätze in Göttingen ausmachen und sich dadurch direkt dahinlotsen lassen ;) Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplatz
Patzi schrieb: Hallo, ich habe gestern schon mein Problem im Forum - http://forum.openstreetmap.org/viewtopic.php?id=385 - geschildert. Ich bin momentan dabei in Göttingen weiter Inhalte zu einzupflegen und zu korrigieren. Dabei ist mir unter anderem ein Parkplatz über den Weg gelaufen siehe: http://www.openstreetmap.org/?lat=51.52882lon=9.88166zoom=17layers=0BFT Da war ein User sehr fleißig und hat jede Parkplatz Linie digitalisiert. Ich würde es jedoch wie in http://wiki.openstreetmap.org/index.php/Mapping/Features/Parking beschrieben handhaben und eine Fläche digitalisieren mit amenity=parking und einen node mit dem Tag in die Mitte pflanzen. Meine Frage ist jetzt ob ich die bereits digitalisierten Wege raushauen soll und nur noch einen weg mit highway=service darüber legen soll. Einfach Sachen rauszuschmeißen wo sich jemand viel Mühe gemacht hat sollte man definitiv vermeiden - insbesondere wenn man neu dabei ist und noch kein Gefühl entwickelt hat. Wenn sich schon jemand die Mühe gemacht hat die Wege einzuzeichnen, warum diese wieder rausschmeißen? Allerdings würde ich da jeweils highway=service nehmen. Zumal viele der Wege nicht miteinander verbunden sind, was aber eine generelles Göttinger Problem ist. Es gibt viele Wege aber häufig nicht verbunden, somit nicht routingfähig. Das ist schlecht! Kann man aber mit JOSM recht einfach nacharbeiten. Ich hätte nun gerne einen kleinen Ratschlag wie ich diesen Parkplatz handhaben soll, da ich recht neu hier bin. Werde mich schon mal ransetzen und das so editieren wie ich es für korrekt halte, Ein korrekt gibt es bei OSM nicht so richtig! Gruß ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplatz
Vielen Dank, Eure Antworten haben mir schon geholfen. Ich werde also jetzt die vorhandenen Wege belassen und das service Tag ergänzen. Sie miteinander verbinden und ne parking Fläche sowie node ergänzen. Aber es ist einleuchtend, mühsame Arbeit nicht einfach kaputt zu machen. Danke erstmal Grüße Patzi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Aus der Kategorie Erfahrungsberichte
Hehe, interessante Idee mit dem Zettel. Aber ist in dem Bald der Empfang besser? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zusammenfassung vom Treffen auf dem 24C3
Andreas Hubel schrieb: Mache regten sich darüber auf, das dass Tagging zu kompliziert ist, sie müssen pft immer zuerst auf Map Features nachschauen, auf Nachfrage kam raus, dass sie die Presets für JOSM nicht kannten. Evtl. schon fest in JOSM mit einbauen? Wo bekommt man diese Presets? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Aus der Kategorie Erfahrungsberichte
Martin Simon schrieb: Hmm wenn Ich nichts von OSM wüßte und einem von euch im Zug begegnen würde, würde ich mir vermutlich auch erstmal an den Kopf packen ;-) Wenn ich so durch die Straßen gehe mit meinem Navi in der Hand und die Leute an mir vorbei gehen, denke ich auch manchmal darüber nach, was die von mir denken könnten. Vielleicht hält mich ja der Eine oder die Andere für einen Terroristen mit ner Fernbedienung für nen Sprengsatz. Man sollte sich mal ans TV wenden und die darum bitten, mal den Publikum zu sagen, dass es sich vor seltsamen Typen, die mit elektrischem Allerlei durch die Straßen ziehen und ggf. auch mitten auf der Straße laufen keine Angst zu haben brauchen. Evtl. sollten wir und so ne Art Uniform in Form einer Weste zulegen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Besenwirtschaft/Strau?wirtschaft/Heckenwirtschaft/...
Michael Bergbauer schrieb: Und du glaubst wirklich, dass die OSM eingetragenen Daten in einem Jahr noch korrekt sein werden? Selbst wenn in einem Jahr sich jemand die Muehe macht und die Oeffnungszeiten nochmals abgleicht, was ist, wenn 14 Tage spaeter ein Wirt seine Oeffnungszeiten aendert? Man kann ja an den guten Willen des Wirtes appellieren (dem die Daten sicher ein paar Kunden einbringen würden), dass er sich doch an irgend eine Adresse wendet oder noch besser - die Daten direkt selbst übernimmt, wenn sie veraltet sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Die Küstenlinien wurden ja grösstenteils bereits Importiert und dort korrigiert. Wurden sie eben nicht - Europa ist zwar weitgehend vollstaendig (selbst da fehlen in Skandinavien glaub ich noch einige Sachen) Der Schein trügt, weil die Renderer die Küstenliniendaten aus verschiedenen Quellen zusammentragen. Wenn man mal hier schaut http://www.openstreetmap.org/?lat=62.1335lon=21.3014zoom=12layers=B0FT sieht alles wunderbar aus, aber wenn man den Editor aktiviert, ist nur noch die Küstenlinie da, aber all die vorgelagerten Inseln fehlen. Und so sieht es an vielen Stellen der finnischen Küste aus. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Eine praktische erweiterung für Pauls script war, wenn die kleinen Seen (4-10 Nodes auf dem Festland) die manchmal generiert werden, gleich als solche getaggt würden. Programmtechnisch gesehen, ist das richtig (abgesehen davon, dass es sehr aufwändig ist, herauszufinden, ob ein geschlossenes Polygon eine Insel ist oder ein See auf dem Festland. Leider aber ist das Datenmaterial sehr grob und teilweise fehlerhaft. Es kommt nicht selten vor, dass solch ein See gar keiner ist, sondern eigentlich eine lange Bucht, die aus unbekannten Gründen in eine kurze Bucht und einen See zerteilt ist. Deshalb kann auf eine manuelle Nachbearbeitung (Vergleich mit Satellitenbildern) kaum verzichtet werden. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Coastline-Programm verbessert
Pauls Programm macht diese Handarbeit leichter, besonders fuer Leute, die nicht mal eben so ein Perl-Skript schreiben, das ihnen irgendwas sortiert oder umdreht ,-) Nein, das Umdrehen ist eigentlich nur ein Zusatz- Gimmick :) Hauptzielgruppe für mein Programm sind vor allem die Leute, die nicht wissen, was Perl ist und was sie mit Deinem Script anzufangen sollen. Und nebenbei die Leute, die sich nicht diese Riesendateien von NGA saugen wollen oder können. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Wie weit sind wir in der Schweiz ?
Hallo zusammen, Gestern (6.1.2008) habe ich die Länge von verschieden ways mit tag railway und highway aus der switzerland mini-planet berechnet und gegen die Swisstopo vector25 und vector200 (Vector Datensatz der Bundesamt für Landestopographie) verglichen. Die Resultat sind in einer Tabelle eingetragen http://wiki.openstreetmap.org/index.php/Ch:current_coverage Es gibt zur Zeit, ca 17598 km highways und 2514 km railway. Die motorway und trunk roads praktisch fertig (90%), 60-70% der Eisenbahnnetz ist gemappt, und 25-30% der Hauptstrassen. Wir haben schon auch mehr als 1000 km footway. Noch etwas erstaunlich, 20% der Waldfläche ist gemappt, vor allem in der Nordost- Ecke! Viele Grüsse Marc (User:Gummibaerli)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erste Test-Daten von OpenGeoDB
Steffen Voß wrote: Naja - diese Listen sind ja nur interessant, wenn man einen Bereich vervollständigen will. Wenn man also meint, dass man bei 100% ist und sicher gehen will, dass das auch so ist. Richtig - so nah dran sind wir aber nur im Einzelfall. Ich bitte da um Rückfrage, wenn jemand dann die Reststraßen haben mag. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
