Re: [talk-ph] [OSMPH GPS:28] Mapping Geodetic Monuments
man_made = survey_point name = CTS-49 operator = NAMRIA Sample here: http://www.openstreetmap.org/browse/node/1287703706 On Sun, Oct 28, 2012 at 2:16 PM, schadow1 schad...@cxsmedia.com wrote: How do we map geodetic monuments like Philippines' PRS92? Thanks! -- You received this message because you are subscribed to the Google Groups OpenStreetMap Philippines GPS Map Development group. To post to this group, send email to osmph-gps-...@googlegroups.com. To unsubscribe from this group, send email to osmph-gps-dev+unsubscr...@googlegroups.com. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-legal-talk] Copyright and license page, how to do the details
I am reading the new copyright and license page, but don't find it very clear to understand. http://www.openstreetmap.org/copyright How to credit OpenStreetMap We require that you use the credit “© OpenStreetMap contributors”. You must also make it clear that the data is available under the Open Database License, and if using our map tiles, that the cartography is licensed as CC-BY-SA. You may do this by linking to this copyright page. Alternatively, and as a requirement if you are distributing OSM in a data form, you can name and link directly to the license(s)... For a browsable electronic map, the credit should appear in the corner of the map. To whom applies the requirement to credit in the corner of the map, just to users of the datatiles or to all users of OSM data presenting it in some form of browsable electronic map? Where does this requirement come from? Or am I misinterpreting this, and should is not a requirement but a recommendation? Crosschecking with the legal FAQ it seems that an about-box/page would be fine as well: http://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F For a browsable electronic map (e.g. embedded in a web page or mobile phone application), the credit should appear in the corner of the map, as commonly seen with map APIs/libraries such as Google Maps, or an about box/page.. cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Copyright and license page, how to do the details
On 28.10.2012 15:11, Martin Koppenhoefer wrote: To whom applies the requirement to credit in the corner of the map, just to users of the datatiles or to all users of OSM data presenting it in some form of browsable electronic map? Where does this requirement come from? Or am I misinterpreting this, and should is not a requirement but a recommendation? I'm also wondering how that recommendation (requirement?) made it onto the copyright page. Based on existing websites and applications using OSM data, this is not at all an universally accepted standard for attribution. In the case of apps/sites intended for mobile usage, it is rare to see attribution in the corner due to screen space constraints. But even for desktop applications, about boxes aren't uncommon either. The only subset of browsable electronic maps where this approach to attribution dominates are slippymaps on websites for desktop usage. The popular slippymap frameworks probably contribute to this because they place it in a corner by default. But even there you will find exceptions among popular websites within the OSM community that have existed for years. This is usually the case where multiple sources are used to create the map, making it impractical to list all of them directly on the map. To summarize, the corner attribution is clearly not the best choice at least in the following cases: * on mobile devices with small screens * when combining several sources that each ask for attribution * with technical limitations (e.g. no hyperlinks in drawing area). So my suggestion is to remove or rephrase that section of the copyright page. It should be allowed to place attribution in a dialog (such as the standard about box user interface convention for desktop apps) or a separate license/sources/about page - which of course must be directly and easily accessible from the site displaying the map. Tobias ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Copyright and license page, how to do the details
Am 28/ott/2012 um 15:11 schrieb Martin Koppenhoefer dieterdre...@gmail.com: just to users of the datatiles or to all users of OSM data presenting it in some form of browsable electronic map? Errata corrige: s/datatiles/standard mapnik rastertiles/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Translating the world
Hi, Some times ago, I used also used data from Wikipedia to complete the names of Japanese cities. But someone pointed out that it is not allowed because: - the Openstreetmap and Wikipedia licenses are not compatible - even if the names cannot be copyrighted, there is in the European Union a database directive that protects the databases (=the result of collecting data; even if it contains only well-known data) in a similar way that the copyright. In the US and in Australia, it would be allowed. So I gave up on that idea and rolled-back my modifications. I limited my modifications to the addition of the wikipedia tag to the japanese train stations (in progress; discussion in the OSM-tagging and japanese mailing lists). I used offline dumps of OSM and Wikipedia, OSMembrane, python scripts and JOSM to do that. Fabien From: *Kolossos* tim.al...@s2002.tu-chemnitz.de mailto:tim.al...@s2002.tu-chemnitz.de Date: Fri, Oct 26, 2012 at 5:27 AM Subject: [OSM-talk] Translating the world To: talk@openstreetmap.org mailto:talk@openstreetmap.org Hello, in the last two weeks I translated all countries in all languages that are available in the unicode-Project CLDR[1]. For this I used Overpass-API link for country codes ISO3166-1[2]. In the second step I translated all capitals in tons of languages by using InterWikiLinks of Wikipedia and Addtags[3] together with Overpass-API[4] and Nominatim. You can check the results for zoom levels 0-6 with map on Wikimedia-toolserver[5], by changing languages under options (You can use up- and down-key). I hope I didn't make more mistakes than native speaker would do by hand. These things were a small step to support multilingual-maps[6] on low zoom levels. For the next steps more people are necessary. In my eyes it seems useful to work as next step on the regions that are regulated in ISO3166-2, but we have no clean tagging schema for this. A source for translation could by a debian project[7], but I need to clarify the legal aspects. Other important thing would be to translate large cities or isles. Any comments and ideas? Greetings Tim alias Kolossos [1]http://cldr.unicode.org/ [2]http://taginfo.openstreetmap.org/keys/country_code_iso3166_1_alpha_2 [3]http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl/Add-tags [4]http://taginfo.openstreetmap.org/tags/capital=yes [5] http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=enzoom=3lat=50.51632lon=5.85569layers=0BTFFF http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=enzoom=3lat=50.51632lon=5.85569layers=0BTFFF [6]http://wiki.openstreetmap.org/wiki/Multilingual_maps_Wikipedia_project [7]http://pkg-isocodes.alioth.debian.org/ ___ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Georepublic UG Georepublic Japan eMail: daniel.ka...@georepublic.de mailto:daniel.ka...@georepublic.de Web: http://georepublic.de http://georepublic.de/ ___ Talk-ja mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Translating the world
Am 27.10.2012 17:10, schrieb Stephan Knauss: Hello Tim, On 25.10.2012 22:27, Kolossos wrote: Other important thing would be to translate large cities or isles. Any comments and ideas? You should certainly get in contact with the local community before doing any sort of mass import of names in a language you don't understand. For example last time your Vietnamese names had not been that satisfactory. Did you read my answer in german Mailinglist and the link to further discussion? *http://wiki.openstreetmap.org/wiki/User_talk:Kolossos#Re:_CLDR_is_an_unreliable.2C_inconsistent_source_for_Vietnamese_names It was not so negative. How about providing an easy to proof-read extract for the local communities before doing the actual import? And maybe also double-checking that the admin boundaries of 3166-2 you're going to use are accurate. My vague idea to do this is to create a table in the wiki. Stephan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Translating the world
Hello, we had this topic on legal-talk one year ago[1] and there were no opposition against my arguments. So it seems to be uncritical. I also present the idea lots of wikipedians and there was also no protest. Wikipedia want's the cooperation with OpenStreetMap and doesn't reclaim database protection. Greetings Kolossos [1]http://lists.openstreetmap.org/pipermail/legal-talk/2011-April/005907.html Am 28.10.2012 14:08, schrieb Fabien SK: Hi, Some times ago, I used also used data from Wikipedia to complete the names of Japanese cities. But someone pointed out that it is not allowed because: - the Openstreetmap and Wikipedia licenses are not compatible - even if the names cannot be copyrighted, there is in the European Union a database directive that protects the databases (=the result of collecting data; even if it contains only well-known data) in a similar way that the copyright. In the US and in Australia, it would be allowed. So I gave up on that idea and rolled-back my modifications. I limited my modifications to the addition of the wikipedia tag to the japanese train stations (in progress; discussion in the OSM-tagging and japanese mailing lists). I used offline dumps of OSM and Wikipedia, OSMembrane, python scripts and JOSM to do that. Fabien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Translating the world
Hello, Thank you a lot for you answer. That seems very positive for the naming of the Japanese places in latin alphabet (now that you said it, it seems obvious that Wikipedia would not sue OSM for using collected well-know data). I hope that there will be no objection that I make and execute another tool to complete the names. Fabien Le 28/10/2012 17:50, Kolossos a écrit : Hello, we had this topic on legal-talk one year ago[1] and there were no opposition against my arguments. So it seems to be uncritical. I also present the idea lots of wikipedians and there was also no protest. Wikipedia want's the cooperation with OpenStreetMap and doesn't reclaim database protection. Greetings Kolossos [1]http://lists.openstreetmap.org/pipermail/legal-talk/2011-April/005907.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Strandtenten en nog niet ingetekende restaurants/winkels
Hallo, Ik ben de bugs voor de regio Haaglanden aan het nalopen om te kijken welke nu kunnen worden opgelost of waar binnenkort een bezoekje vereist is. Twee dingen vallen mij op. Het eerst zijn strandtenten welke eigenlijk alleen in een bepaald seizoen (april-oktober) op het zand staan en de strandtenten bij de boulevard in Scheveningen zijn redelijk stabiel qua locatie en sommige bij Kijkduinen en het zuiderstrand ook. Helaas zijn er ook strandtenten op het noorderstrand die gerust 500 meter per jaar wandelen. Iemand suggesties om hoe hier mee om te gaan? Bij oa Katwijk lijken ze te worden getekend als permanente gebouwen. Of staan deze locaties ook in de BAG zover iemand weet. Ze zouden te boek moeten staan als Strandweg, Scheveningen of Strandweg, 's-Gravenhage. De ander is dat mensen melden dat hun restaurant/winkel niet op de kaart staat. In plaats van dit handmatig bij te houden, zijn er mensen al aan het kijken naar een soort koppeling/mapping tussen de BAG en bijvoorbeeld OpenKvK-data (nog niet naar de licentie gekeken, maar ze bieden wel een mooie RSS-feed met alle updates) zodat dit behapbaar is. Hans ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Preparing to map.
I see that Port Macquarie and Wauchope need quite a bit of remedial work done on them. On my way to the Pan-Pac Games this week, I am going to try to acheive some of this. I started by realigning those roads that redaction had caused to misalign. Then I traced in those roads that went missing. I tagged them, temporarly, just as highway=road, so that they stand out. Then I changed those roads that didn't have a name to highway=road as well. Now what I'll do is make up a set of custom poi's with a coordinate from each of these road. That way my Garmin sat-nav will direct me to the nearest road that needs attention. I've found that there were a LOT of roads originally just traced in but then never surveyed at all, so there is so much work to do that I am going to try to do it fast. I'll have multiple loggers going and will be recording the street names via audio so that I don't have to stop to photograph or note down stuff. When I need to geo-locate my recording I will just voice record a time and simultaneously tag a waypoint on one of the loggers. Then, at night I'll edit it all in and maybe pretty it up a bit. Now , what would be *really* useful, is if someone/or two could check what I've done, maybe on Monday-week onwards. By checking OSM against some other maps (street directories etc) if you spot any spelling mistakes I've made or any roads I've failed to edit or name, then if you could note down the lat/long and drop me a message or note them to this list. That way, on my way back the following week, I can correct mistakes and complete the job. Then if I have any time left, I'll duck over to Wauchope, which needs a complete mapping, and get started there. Nick PS - there were some real problems with Port Macquarie that the redaction bot cleaned out nicely for us, so I think we could end up with a really nice Port Macquarie, which is only fitting for such a nice place! ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] [Imports] Importing locality names from GeoScience Australia dataset.
On 27/10/12 18:52, Chris Barham wrote: Hi, On Sat, Oct 27, 2012 at 6:48 AM, Li Xia lisxia1...@gmail.com mailto:lisxia1...@gmail.com wrote: SNIP 1. Can anyone suggest tags other than the following? name:different place:locality source: © Commonwealth of Australia (GeoScience Australia) 2006. 2. Using JOSM at the moment and uploads take a while, is there a better way of bulk uploading data? /SNIP Some questions for you: 1) Can you post a link to the source data and licence? 2) that copyright tag looks ominous, are you sure it's licenced appropriately for import to OSM? a) The site http://ga.gov.au has a footer that says: Unless otherwise noted, all Geoscience Australia material on this website is licensed under the Creative Commons Attribution 3.0 Australia Licence. I believe this may not compatible with OSM... CC-By-SA 3.0 Australia Licence is not automatic permission to use it in an ODBL database. Cheers Ross b) ...Unless you got the data from http://data.gov.au/ for which OSM has obtained rights to import ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] 4wd_only Tag - is it the right choice ?
You point out the problem with this: tracktype is ignored on everything except highway=track You would have to modify this in the rendering anyway. As 4wd_only can apply to any highway= tag it is more appropriate. From memory this was part of the original discussion when 4wd_only was proposed. Additionally my feeling is that because it's not rendered it's not used and Australian understanding of 4WD is definitely different to the European understanding. Have a look through the original proposal on the wiki and also the smoothness discussion Cheers Ross On 28/10/12 11:00, David Bannon wrote: Now, I am not suggesting that tracktype is a dropin replacement for 4wd_only, far from it, the definition I read says to me it stops before 4wd_only (see http://wiki.openstreetmap.org/wiki/Key:tracktype ) but we might find getting a grade 6 and grade 7 (or better still, 4wdRecommended and 4wdOnly) added to tracktype easier than getting 4wd_only=recommended added to the list. And if we do, then with all those numbers, we may be able to get special rendering, and, importantly special routing rules apply to them. Indeed, seems that at present, all five grades of tracktype are rendered differently. Ranges from grade one as a thin but solid brown line to grade5's small dots. So, I know this is not what was discussed, but do people want to re think the agreed position ? David ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Voradvents-Mappingparty in Schönberg/Mecklenburg
in Weiterleitung von Rainer Moin, bei dem letzten Lübecker Stammtisch haben wir darüber philosophiert, dass wir demnächst zu einer Mappingparty im Lübecker Umfeld einladen wollen. Ich hab mich der Idee mal angenommen, wobei mein Blick sofort auf das östlich an Lübeck angrenzende Nordwest-Mecklenburg fiel, da hier noch erheblicher Mappingbedarf besteht (es gibt hier sogar noch die andernorts schon so schmerzlich vermissten weißen Flächen ;-) ). Ausgeguckter Zielort ist Schönberg/Mecklenburg [1] http://www.openstreetmap.org/?lat=53.85lon=10.935zoom=15layers=M; das Städtchen liegt an der Bahnlinie Lübeck-Bad Kleinen - mit Bahnhof, ist also recht gut zu erreichen. Vorab habe ich schon mal Räumlichkeiten im Gebäude der Freiwilligen Feuerwehr http://www.openstreetmap.org/?way=158297080 [2] für Samstag, den 24.11.2012 reserviert. Einen WLAN-Anschluss gibt's dort wohl auch. Bevor wir mit der Detailplanung beginnen, möchte ich mal in die Runde fragen, wer 'in der kalten Jahreszeit' - voraussichtlich - kommen würde. Sofern sich bis nächsten Do, 1.11. (also zu unserem nächsten Lübecker Stammtisch) etwa acht (oder mehr :-) ) Interessenten finden, würden wir die Vorbereitungen fortsetzen; ansonsten verschieben wir die ganze Aktion in Richtung Mai 2013 ... Insofern bei Interesse bitte rechtzeitig 'Signal geben' ... Involviert in die Vorbereitungen sind derzeit auch Jan aus Lübeck und Wolfgang aus Hamburg ... Diese Rundmail läuft über die Mailing-Listen Lübeck, Hamburg und MeckPomm. Viele Grüße aus Lübeck Rainer alias projecter63 [1] http://www.openstreetmap.org/?lat=53.85lon=10.935zoom=15layers=M [2] http://www.openstreetmap.org/?way=158297080 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Plugin no_more_mapping
fly wrote: Also der Sinn hat sich ja auf der josm-dev geklärt. Ist das so? Ich habe die Liste überflogen, den Thread aber leider nicht gefunden. Kannst du bitte noch einen Link ins Archiv nachreichen? Allerdings finde ich die Entscheidung von Frederik schon ein bisschen überzogen. Das Plugin hat keinen Schaden verursacht und bei open source gibt es nie eine Garantie. Falsch. Bei so manchem OSS-Projekt hat man sogar noch deutlich mehr Sicherheit. Bei Firefox-Addons zum Beispiel. Die werden generell erst von einem Reviewer begutachtet bevor sie auf die Benutzer losgelassen werden. Ich frage mich in dem Zusammenhang eher ob eigentlich jeder ein Josm-Plugin bauen und auf die öffentliche Liste setzen kann, ohne das vorher da jemand nochmal drüberschaut. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Plugin no_more_mapping
On 28.10.2012 11:12, Manuel Reimer wrote: fly wrote: Also der Sinn hat sich ja auf der josm-dev geklärt. Ist das so? Ich habe die Liste überflogen, den Thread aber leider nicht gefunden. Das hat jemand geschrieben um seine OSM-Sucht in den Griff zu bekommen. Passiert wohl häufiger. Ich habe einen Kollegen der daheim in der Firewall den Zugriff auf die Firmenmail geblockt hat, damit er nicht in Versuchung kommt. Und eine ehemalige Kollegin hat das Kabel zum Modem durchgeschnitten um vom Internet wegzukommen. Vor dem Hintergrund hat so ein Plugin schon seine Berechtigung. Ich möchte es aber ungern in DER Pluginliste sehen. Nicht nur weil jemand vielleicht einfach alle Plugins installiert, sondern auch weil man ja versehentlich danebenklicken kann. Wie genau die Warnungen von dem no_more_mapping plugin ausgesehen haben kann ich nicht sagen, da das Plugin recht schnell weg war. Vielleicht hätte das auch gereicht um das Plugin unmöglich versehentlich zu installieren. Ich frage mich in dem Zusammenhang eher ob eigentlich jeder ein Josm-Plugin bauen und auf die öffentliche Liste setzen kann, ohne das vorher da jemand nochmal drüberschaut. Im Prinzip ja. Du brauchst einen Zugang zum svn oder hier: https://josm.openstreetmap.de/wiki/Plugins SVN lässt sich wohl noch einfach nachverfolgen, schwieriger wird es mit externen Plugins. Wir könnten die Plugins signieren. In JOSM kommt eine Whitelist mit vertrauenswürdigne Autoren mit, die ihre Plugins auch pflegen. Sprich es wird dort der Public Key hinterlegt. Bei anderen Plugins (oder wenn die Signatur nicht stimmt) muss der Benutzer eine Warnung abnicken. Der Mehraufwand beim Deployment hält sich in Grenzen. Ich hatte damals den Windows-Installer für T@H auch signiert. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Plugin no_more_mapping
Stephan Knauss wrote Wie genau die Warnungen von dem no_more_mapping plugin ausgesehen haben kann ich nicht sagen, da das Plugin recht schnell weg war. Vielleicht hätte das auch gereicht um das Plugin unmöglich versehentlich zu installieren. Das Plugin ist inzwischen im aktuellen SVN wieder drin - allerdings entschärft. Ganz am Anfang ist ein bewusster Systax-Verstoß eingebaut, der ein Kompilieren verhindert. (Remove this garbage line if you really want to compile the plugin.) Dadurch kann sich jeder das Teil ansehen und auch für sich aktivieren. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/JOSM-Plugin-no-more-mapping-tp5731892p5733166.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Plugin no_more_mapping
Hallo, On 10/28/12 12:21, Walter Nordmann wrote: Das Plugin ist inzwischen im aktuellen SVN wieder drin - allerdings entschärft. Ganz am Anfang ist ein bewusster Systax-Verstoß eingebaut, der ein Kompilieren verhindert. (Remove this garbage line if you really want to compile the plugin.) Ja, ich denke, es war eine Ueberreaktion von mir, den *source* zu loeschen, es haette je gereicht, das Binary zu loeschen, um das Plugin aus der JOSM-Downloadliste zu streichen. Dabei habe ich aber dann diese Zeile eingebaut, hauptsaechlich, um zu verhindern, dass irgendein schlaues Skript irgendwo alle Plugins durchguckt und automatisch compiliert und in die Downloadliste reintut ;) In der Tat kann derzeit jeder, auch anonym, Plugins in die offizielle Downloadliste eintragen; es findet keine Vorab-Pruefung statt. Mit dem Signieren kenne ich mich nicht so aus, aber wenn man damit irgendwas erreichen koennte, dass JOSM Plugins in zwei Gruppen unterteilt, signierte und unsignierte, und dem User so ein Haeckchen anbietet auch unsignierte Plugins zeigen, waer das vielleicht gar nicht schlecht - bloss wer entscheidet, was signiert wird? Gibt wieder Mehrarbeit fuer irgendjemanden. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Plugin no_more_mapping
On 28/10/12 13:57, Frederik Ramm wrote: Hallo, On 10/28/12 12:21, Walter Nordmann wrote: Das Plugin ist inzwischen im aktuellen SVN wieder drin - allerdings entschärft. Ganz am Anfang ist ein bewusster Systax-Verstoß eingebaut, der ein Kompilieren verhindert. (Remove this garbage line if you really want to compile the plugin.) Ja, ich denke, es war eine Ueberreaktion von mir, den *source* zu loeschen, es haette je gereicht, das Binary zu loeschen, um das Plugin aus der JOSM-Downloadliste zu streichen. Super, wenn Du das selber so einsiehst und danke. In der Tat kann derzeit jeder, auch anonym, Plugins in die offizielle Downloadliste eintragen; es findet keine Vorab-Pruefung statt. Mit dem Signieren kenne ich mich nicht so aus, aber wenn man damit irgendwas erreichen koennte, dass JOSM Plugins in zwei Gruppen unterteilt, signierte und unsignierte, und dem User so ein Haeckchen anbietet auch unsignierte Plugins zeigen, waer das vielleicht gar nicht schlecht - bloss wer entscheidet, was signiert wird? Gibt wieder Mehrarbeit fuer irgendjemanden. JOSM ist in dieser Hinsicht sehr liberal und bisher gab es auch nur wenig Probleme. Signieren ist schon eine schöne Sache, hilft uns aber hier nicht weiter. 1. Haben wir wieder das gleiche Problem wie am Anfang: Die BenutzerInnen achten auch hier nicht darauf von wem der Kode kommt. 2. Entwickler zverik ist bekannt und hat schon andere Erweiterungen entwickelt sowie einige Patches für JOSM geschrieben. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 119
Hallo, die Wochennotiz Nr. 119 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2012/10/wochennotiz-nr-119/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Tag per edicole o giornalai
Il 27/10/2012 17:20, Roby Libero ha scritto: Stavo inserendo le edicole nella mia zona, e come tag ho trovato soltanto questo shop =newsagent . è quello giusto Se vado però nella mappa di OSM queste non compaiono con la loro iconcina. è normale, non è stata ancora messa una icona per quel POI in mapnik (lo stile ufficiale della mappa osm), bisogna aspettarecomunque, invece di inserire un semplice nodo, puoi tracciare una linea chiusa intorno al chiosco del giornalaio e mettere un tag building=kiosk insieme al tag shop=newsagent, con eventuale name=giornalaio vattelappesca. almeno così sulla mappa osm si vedrà un piccolo edificio col nome ;) per nominatim, edita la pagina wiki consigliata da alberto nogaro -- http://goo.gl/maps/igIxf ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] http://gis.19327.n5.nabble.com/Places-amp-admin-boundaries-td5733103.html
Sulla mailing list di tagging è nata una discussione sul problema del tagging dei place=* su nodi o poligoni e sulle relazioni boundary. Ho segnalato la proposta che Simone ha scritto poco tempo fa [2], secondo me sarebbe il caso di prendere la palla al balzo e portare avanti la proposta, magari aprendo ufficialmente la fase di discussione RFC. Che ne dite? [1] http://gis.19327.n5.nabble.com/Places-amp-admin-boundaries-td5733103.html [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Urban_settlements Ciao Alberto Viking81 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] URGENTE: aggiornare licenza in italiano
è ora a posto: http://www.openstreetmap.org/copyright 2012/10/14 Simone Cortesi sim...@cortesi.com: 2012/10/10 Luca Delucchi lucadel...@gmail.com: Il 10 ottobre 2012 10:50, Simone Cortesi sim...@cortesi.com ha scritto: La traduzione è stata aggiornata nel repository di translatewiki, ma non ancora copiata sul web principale. Penso sia un problema comune a tutti. ok, come possiamo a fare pressone per copiarla? credo che sia una grossa falla di sicurezza :-) avevo fatto casino io. la traduzione corretta adesso è in translatewiki c'è. verra messa online al prossimo aggiornamento settimanale. -- -S -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] roundabouts - update 2012-10-24
Date - total -ok - fixed 2012-10-15 NORTH - 25355 - 25228 - 127 2012-10-20 - 25343 - 25330 (99.95 %) - 13 (0.05 %) 2012-10-24 - 25372 - 25362 (99.96 %) - 10 (0.04 %) 2012-10-15 SOUTH - 14304 - 14107- 197 2012-10-20- 14462 - 14429 (99.77 %) - 33 (0.2 %) 2012-10-24- 14478 - 14445 (99.77 %) - 33 (0.2 %) After checking the latest version of both files, there was only one roundabout that was missing the correct direction, and I have just corrected it, so it seems that the project is now complete. Thank you Jan for bringing this issue to the list and to all that one way or the other helped fix this thing. Cheers. -- Jose Luis Domingo Lopez Linux Registered User #189436, Linux Ubuntu 12.04.1 LTS (3.2.0-32-generic-pae) signature.asc Description: Digital signature ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Österreichweite Verkehrsauskunft
Wenn ich es richtig verstanden habe, kommen die Daten vorerst aus den diversen Länder-GIS und werden somit unter einer ähnlichen Lizenz stehen. Am 27.10.2012 14:30, schrieb Alex Barth: Hat jemand von euch mehr Hintergrundinformationen oder weitere Artikel zu dieser Initiative des Verkehrsministeriums? zB - werden die Daten dieses Systems lizenztechnisch gesehen für OSM zur Verfügung stehen? http://orf.at/stories/2147817/ http://verkehrsauskunft.at/ Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec
Bonjour Daniel, Retour à la case départ. J'aurais dû commencer par lire plus en détail la documentation du produit. voir http://ivt.crepuq.qc.ca/recensements/recensement2011/documentation/92-162-g2010001-fra.pdf Tous droits réservés. Le contenu de la présente publication électronique peut être reproduit en tout ou en partie, et par quelque moyen que ce soit, sans autre permission de Statistique Canada, sous réserve que la reproduction soit effectuée uniquement à des fi ns d’étude privée, de recherche, de critique, de compte rendu ou en vue d’en préparer un résumé destiné aux journaux et/ou à des fi ns non commerciales. Compte-tenu du fait que les fichiers de Geobase n'ont pas une couverture complète du territoire (ie. territoires non organisés, innus et innuits manquants), je pense qu'il est mieux de ne pas les importer. Du côté de Statistique Canada, y-aurait-il des chances quelconques qu'ils acceptent de faire une exception et nous permettre d'importer dans OSM? Je vais relancer les responsables du gouvernement du Québec et demander d'ajouter ces données au site de données libres. Pierre De : Daniel Begin jfd...@hotmail.com À : 'Pierre Béland' infosbelas-...@yahoo.fr; 'talk-ca' talk-ca@openstreetmap.org Envoyé le : Samedi 27 octobre 2012 22h21 Objet : RE: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec Bonjour Pierre, and all Osmers Limites de StatCan ou GeoBase? Bonne Question! Les limites de GeoBase sont ce qu'il y a de plus près des limites légales, mais comme tu a remarqué, elle sont incomplètes pour certains niveaux administratif (admin_level) A ma connaissance, les limites de StatCan ... a) Ne suivent pas toujours les limites légales, particulièrement si la limite légale ne correspond pas a un objet physique comme une route, un chemin de fer, ou une rivière; b) Leur géométrie est différente des données GeoBase/Canvec. Autrement dit, une limite légale qui repose sur une limite physique (route, un chemin de fer, ou une rivière) ne correspondra pas nécessairement à la géométrie de l'objet dans OSM, même si celui-ci a été obtenu de GeoBase ou de Canvec. Gros travail d'intégration en perspective... C'était du moins le cas il y a quelques années - Ce sera a vérifier avant de prendre une décision. Daniel From:Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: October-27-12 20:34 To: talk-ca Subject: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec Au cours des dernières semaines, j'ai examiné les données pouvant être importées pour définir les limites administratives des municipalités, MRC et régions administratives du Québec. J'ai déja indiqué dans un courriel précédent, les données importées par des contributeurs à Saint-Jean-sur-Richelieu, Montréal, Labelle et Québec. De plus, des données importées pour Brossard et Laprairie sont mal définies et devront être corrigées. À mon avis, il faut éviter d'importer à la pièce les limites des villes, sinon le travail de vérification / correction sera immense. Pour deux municipalités ayant une frontière commune, si les limites sont différentes, il y aura beaucoup de travail de réconciliation. Sur le site des données ouvertes du gouvernement du Québec, j'ai fait une demande pour obtenir les limites administratives du Québec avec licence ODbl. Aucune nouvelle depuis quelques mois. J'ai examiné les données de Geobase ajoutées récemment pour le Québec. Suite à l'examen de cess données, je constate qu'il faut utiliser deux fichiers différents : 1. limites de municipalités (source initiale, gouvernement du Québec). 2. limites des territoires autochtones. J'ai constaté que certains territoires innus et tous les territoires inniuits sont absents. Les territoires non organisés, les MRC et les régions ne sont pas décrits. Comparativement, le fichier des limites de recensement de Statistique Canada est complèt. Une subdivision de recensement est une municipalité ou un territoire considéré comme étant équivalent à des fins statistiques (par exemple une réserve indienne ou un territoire non organisé). voir http://www5.statcan.gc.ca/bsolc/olc-cel/olc-cel?lang=fracatno=92-162-XWF Les limites sont assez prêts de celles de Geobase. municipalités, territoires non organisés, territoires autochtones incluant innus et innuits, MRC et régions administratives. Je suggère donc que nous examinions la possibilité d'importer les données de Statistique Canada pour définir les limites administratives des municipalités, MRC et régions administratives. Je crois que le fichier le plus récent est à l'adresse suivante : http://www.statcan.gc.ca/pub/92-196-x/2011001/spa-fra.htm À mon avis, il vaudra mieux remplacer les limites déja saisies pour faciliter le travail et assurer une cohérence de l'ensemble de données. Est-ce que d'autres personnes veulent examiner ces données? Sinon, acceptez-vous que
Re: [OSM-talk-fr] Organisation d'une cartopartie à Argenteuil ?
Retour presse sur la cartopartie d'hier à Argenteuil: http://www.leparisien.fr/val-d-oise-95/des-benevoles-enrichissent-les-cartes-a-argenteuil-28-10-2012-2271975.php Vu le vent, le froid et la pluie qui voulait elle aussi participer, nous avons inversé le programme en passant notre après-midi à découvrir les outils d'édition, un petit peu Potlatch et surtout JOSM. Nous avons travaillé sur des photos géolocalisées que j'avais pris lorsque j'était venu sur place pour une réunion de préparation avec l'Espace Numérique. Toujours prévoir un plan B ! La suite lundi à partir de 14h avec des relevés sur le terrain et sûrement encore de la manipulation dans JOSM... Le 26 octobre 2012 17:37, Christian Quest cqu...@openstreetmap.fr a écrit : Samedi c'est la journée de présentation + relevé sur le terrain Lundi, ça sera les manip sur les ordi (Potlatch/JOSM) Si tu veux venir pour déjeuner ensemble lundi... sinon c'est de 14 à 18h Le 26 octobre 2012 10:44, Olivier Perret pepelemoqu...@free.fr a écrit : Christian Quest (Le Mon, Oct 22, 2012 at 06:25:20PM +0200): La première cartopartie d'Argenteuil se tiendra samedi qui vient à partir de 14h: http://openstreetmap.fr/cartopartie-argenteuil-toussaint Lundi après-midi sera consacré à la saisie des données. Ca tombe bien je me suis justement inscrit sur le framadate le week-end dernier pour te proposer mon aide les jours ou Marc n'était pas dispo. Je te confirme donc ma disponibilité pour lundi et malheureusement mon absence samedi. Je n'ai pas le niveau pour animer la cartopartie, mais s'il y a des corvées à la portée d'un jeune mappeur plutôt à l'aise avec les machines, c'est avec plaisir que je t'en déchargerai. Dans les trucs possiblement utiles, j'ai un véhicule (s'il y a des trucs à transporter ou si ça peut faire gagner du temps à quelqu'un). A lundi. -- Olivier Perret ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout d'un POI
Le 27 oct. 2012 à 23:34, Christian Rogel a écrit : Le 27 oct. 2012 à 19:32, Francescu GAROBY a écrit : Pour le tag 'addr:state', j'aurais plutôt mis 'France, comme valeur... De toute façon, je ne mets jamais ce tag. Et pour les numéros de téléphone, je suis contre les espaces : c'est au système de rendu de choisir le format, en fonction des habitudes du pays (2 chiffres, 3 chiffres, ...). Il me semble que state est là pour les Etats fédérés (USA, Canada, mais, il y en a beaucoup d'autres), l'Etat englobant étant implicite. Mettre les régions n'est pas inepte, mais comme cela n'a pas le même intérêt… Ok, je supprime ce tag addr:state vu qu'il ne s'applique pas en France. Par contre, pour les numéros de téléphone, j'ai mis les espaces pour être en accord avec cette page du wiki : http://wiki.openstreetmap.org/wiki/Key:contact:phone, qui indique de mettre un espace entre country_code et national_destination_code, ainsi qu'entre national_destination_code et subscriber_number. Si ça ne convient pas, je pourrais toujours le modifier par la suite. :) -- Brice Hardy hardybr...@gmail.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout d'un POI
Le 28 octobre 2012 11:04, Brice Hardy hardybr...@gmail.com a écrit : Le 27 oct. 2012 à 23:34, Christian Rogel a écrit : Ok, je supprime ce tag addr:state vu qu'il ne s'applique pas en France. Par contre, pour les numéros de téléphone, j'ai mis les espaces pour être en accord avec cette page du wiki : http://wiki.openstreetmap.org/wiki/Key:contact:phone, qui indique de mettre un espace entre country_code et national_destination_code, ainsi qu'entre national_destination_code et subscriber_number. Si ça ne convient pas, je pourrais toujours le modifier par la suite. :) Pour la France country-code = 33, il n'y a plus de national-destination-code (depuis la numérotation à 10 chiffres), et le subscriber number est les 9 derniers chiffres. Cependant pour bien indiquer que c'est un numéro international, si on indique le 33, il faut le préfixer d'un +. Les numéros sans le + sont supposés n'être que des numéros nationaux (pas forcément appelables depuis l'étranger). Donc le format est +33 123456789 (pour le 01 23 45 67 89 en France). Mais on ne mettra PAS de préfixe +33 si c'est un numéro court national (par exemple le 3310). Le + reste nécessaire dans le format international des numéros géographiques ou mobiles, pour éviter l'ambiguité avec des numéros courts nationaux : c'est une norme internationale (utilisable aussi pour appeler depuis un mobile en maintenant le 0 enfoncé pour qu'il se change en + avant de composer le code pays). Dans nombre de courriers et fiches de contacts d'une carte de visite ou d'un carnet d'adresses le même numéro serait affiché préférablement sous la forme +33 (0)1 23 45 67 89. Ce zéro entre parenthèses rappelle qu'il est nécessaire en France, mais doit être omis dans un appel depuis un autre pays. Ce zéro entre parenthèses n'est pas en France partie d'un national-code, c'est juste un préfixe de sélection d'opérateur (qui sert aussi à distinguer les numéros courts strictement nationaux, des numéros appelables depuis l'étranger et dits à 10 chiffres pour les lignes géographiques, mobiles ou VoIP des box Internet). Au Royaume-Uni, il y a des indicatifs de zones : ils commencent aussi par un 0 qui, en revanche, DOIT être composé depuis l'international (le Royaume-Uni ne restreint pas les numéros courts qui peuvent être souvent (pas toujours) appelés depuis un autre pays indépendamment du format national). Par exemple: +44 0144 1234567 (au Royaume-Uni on peut alors composer seulement le 1234567 si on est dans la zone 0144, sinon on compose les 11 chiffres 01441234567, depuis la France on appelerait le 004401441234567). Ce numéro est souvent présenté sur les cartes de visite sous la forme: +44(0144)123.4567 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] OSC会津への参加について
ikiyaです。 OSC会津 開催の再告知です。 オープンソースカンファレンス2012 Aizu http://www.ospn.jp/osc2012-aizu/ 日程：2012年11月3日(土) 会場：会津大学 講義棟 M8・M9教室 OpenStreetMap Japan出展します。 朝から会場にいますので お時間ありましたらぜひどうぞ。 OpenStreetMapについてワイワイお話しましょう。 ライトニングトークでは東さんが「オープンなデータのライセンスとは」発表されます。 個人的にはハンディGPSログの比較デモできればと考えています。 6台ぐらいセットできるGPS台？作っていきますので比較されたい方は GPSご持参願います。 大学グランドと公園の間に四等三角点（震災で動いて改算）もあるので ご自分のハンディGPSで測ってみるのも面白いと思います。 --- On Thu, 2012/9/13, Takahisa TAGUCHI caes...@mbp.nifty.com wrote: たぐちです。 東さん、ikiyaさん ありがとうございます。こちらこそよろしくお願いします。 なるほど、、、そうすると会津周辺はロギングし甲斐のある場所ですね。東京より比較的近いですし、ちょうど紅葉の時期でもあるので、電車以外の方法で行って翌日周辺を巡るのもおもしろいかなと考えているとこです。 2012年9月13日 11:06 ikiya insidekiwi...@yahoo.co.jp: ikiyaです。 11/3参加いたします。宜しくお願いします。 現在、会津若松市内は高解像度Bing写真、基盤地図情報2500いずれも 公開されていません。GPSログと現地調査がメインのトレースエリアです。 大学はそんなに広くないので3日（土）のOSC開催中に 会津大学のキャンパスマッピングを 展示説明と並行して参加者とカリカリできればいいなと思っています。 たぶん時間はありそうなのでよいキャンパスマップできるかと思います。 （わからないところがあればちょっと見に行ってくるという感じで） http://www.openstreetmap.org/?lat=37.52376lon=139.93815zoom=17layers=M Shu Higashi s_hig...@mua.biglobe.ne.jp wrote: あ、調整中ですが私も検討中です。 参加の場合はセミナーを申し込みたいと思っています。 東 2012/09/11 Takahisa TAGUCHI caes...@mbp.nifty.com: 田口です。 会津の件、参加申込書を送付しました。 当日参加される皆さん、どうぞよろしくお願いします。 2012年9月10日 18:02 loglogy logl...@gmail.com: 多分今のところ、参加出来ると思います。 皆様、SotMお疲れ様でした。 iPadから送信 On H.24/09/10, at 16:25, Takahisa TAGUCHI caes...@mbp.nifty.com wrote: 田口です。 現在参加募集中のOSC会津について、一部の人には SotM でご相談させて いただきましたが、私のほうで出展する方向で考えてたいと思います。 ひとまず申込書を送付しようと思っておりますが、現時点で他に参加できそう方は いらっしゃいますでしょうか？ 参加者数が少ない場合は、OSC北海道と同様に「小江戸らぐ」との合同出展に したいと思っております。 ＜OSC会津 開催概要＞ 日程：2012年11月3日(土) 会場：会津大学 講義棟 M8・M9教室 アクセス：http://www.u-aizu.ac.jp/access.html http://osm.org/go/7RuRWfuw-- http://goo.gl/maps/YjPw1 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] NHD imports
In June, user Bsupnik converted the entire NHD dataset into OSM format. The files are available at http://bsupnik.dev.openstreetmap.org/NHD. He mentioned that he was working on creating better quality files. The files that he created look good. They are missing the names though. It looks like they just need a couple minor tweaks because the files generally looked good. Just wondering if any progress has been made. These would be ideal once the bugs are worked out so people could review and upload the data in their area. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD imports
From: Nathan Mixter [mailto:nmix...@gmail.com] Sent: Sunday, October 28, 2012 1:39 PM To: talk-us Subject: Re: [Talk-us] NHD imports In June, user Bsupnik converted the entire NHD dataset into OSM format. The files are available at http://bsupnik.dev.openstreetmap.org/NHD. He mentioned that he was working on creating better quality files. The files that he created look good. They are missing the names though. It looks like they just need a couple minor tweaks because the files generally looked good. Just wondering if any progress has been made. These would be ideal once the bugs are worked out so people could review and upload the data in their area. I downloaded a random area (17010104) and looked at these. There were no real OSM tags on the ways, only gnis:fcode, gnis:ftype, nhd:com_id and source. I'd question anyone proposing an import with both fcode and ftype because ftype can be inferred from fcode. Also, it suffers from an inherent limitation by splitting it up among multiple files. This method loses the connections between the layers, resulting in duplicate nodes and the topology not being connected. I looked at a separate-layer approach when I first started looking at NHD and with how NHD is structured with many interdependent layers it doesn't make sense to do it that way. You have to merge all the layers together as a multi-layer file and then convert to OSM. I'm not sure if shp-to-osm can handle multi-layer sources. A couple of other specific issues with these conversions: - They're of 2011 data, not the latest NHD data - I wasn't able to find a rules file from bsupnik for the conversion, so they can't be rerun with latest data. He hasn't been active on the lists since 2011 and hasn't replied - The NHD data model changed since 2011 If anyone is aware of where the file with the rules bsupnik used resides, please let me know. It would really help what I'm working on. Also, needless to say, someone who wanted to import a basin would need to read and follow http://wiki.openstreetmap.org/wiki/Import/Guidelines ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] What to do with unnamed NHD streams
Background: I'm working on converting NHD to .osm format NHD is an extremely large data set. It's about 25G of zipfiles and all of this converted to .osm would total about 3 TB. This is about 10x-15x times the size of planet.osm. There are three factors that lead to this large size. The third is what this email is about 1. The NHD covers a massive area. 2. Some ways are very over-noded. The NHD accuracy standard is 12m error 90% of the time. Running a 1m simplify in JOSM reduces the number of nodes to 25%-50% of what it was before. Like everything with the NHD, this varies from region to region. I'm thinking a 2.5m simplification would be best - it's 1/5th of the accuracy standard. Of course, running a simplification on a dataset this large is a challenge in itself. 3. A lot of NHD is very minor streams only of use to hydrologists. There are streams that you would be hard pressed to locate if you were there in person and in some cases they do not exist anymore. A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. I've looked at a couple of regions with this adjustment made and they seem a lot more reasonable. The data is a lot more manageable and of more relevance to a general purpose map like OSM. There are also a lot fewer cases of streams that no longer exist. Does anyone have any thoughts on what should be done in a NHD translation with these streams? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
From: Michal Migurski [mailto:m...@teczno.com] Sent: Sunday, October 28, 2012 8:58 PM To: OpenStreetMap US Talk Subject: Re: [Talk-us] What to do with unnamed NHD streams Does [NHD] all come in shapefile form? The simplification would be a relatively easy (though time-consuming) task for PostGIS on a server with sufficient storage, outputting new shapefiles for ogr2osm. I can help with this using one of our office servers that we use for such tasks. It comes in .mdb or .gdb form. These could be loaded into postgis and I've considered doing it. My home server has the storage and cores to do it, but I don't think it would help. The problem is you need to convert to .osm and *then* simplify. If you do this in the other order you have problems where one object intersects another (e.g. because they share a geometry for a portion of them). You end up simplifying away the intersection points and your resulting ways won't end up correctly sharing nodes. The most common example of this is when a stream meets a lake. At the meeting point you have a FCode 55800 from NHDFlowline in the water, a FCode 4600x from NHDFlowline on the land side and a FCode 390xx or 436xx from NHDArea as the bounds of the lake. Without simplification the output will have the three ways sharing a node at the intersection point. If you simplify before converting you could simplify away the point on the NHDArea and then you'll no longer have the node sharing. You can run into similar issues where a simplification of a NHDFlowline takes it away from a NHDPoint, resulting in the point no longer being on the line. I would *really* like to be able to simplify prior to ogr2osm as it would dramatically decrease the size of the nodes data in-memory and decrease conversion time, I just can't see how to do it prior to processing. JOSM's simplify ways function works okay, although it doesn't deal with the case of two ways sharing nodes very well. 3. A lot of NHD is very minor streams only of use to hydrologists. There are streams that you would be hard pressed to locate if you were there in person and in some cases they do not exist anymore. A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. Can these be simplified to a lower level of accuracy? In principle yes, and I'll try it with JOSM. I'm not sure how it'd turn out. I have a feeling it will still result in a lot of low-value ways. Perhaps drop nameless 46003 which often don't correspond to anything noticeable and use heavier simplification on 46006? I'm not convinced this would be a good option, but I'll see how it looks in a couple basins. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] What to do with unnamed NHD streams
On Sun, Oct 28, 2012 at 8:51 PM, Paul Norman penor...@mac.com wrote: Background: I'm working on converting NHD to .osm format NHD is an extremely large data set. It's about 25G of zipfiles and all of this converted to .osm would total about 3 TB. This is about 10x-15x times the size of planet.osm. There are three factors that lead to this large size. The third is what this email is about 3. A lot of NHD is very minor streams only of use to hydrologists. There are streams that you would be hard pressed to locate if you were there in person and in some cases they do not exist anymore. A sensible solution in any NHD translation may be to drop any FCode 46003 (intermittent) streams without a name. It may also be worth dropping FCode 46006 (perennial) streams without a name. I've looked at a couple of regions with this adjustment made and they seem a lot more reasonable. The data is a lot more manageable and of more relevance to a general purpose map like OSM. There are also a lot fewer cases of streams that no longer exist. Does anyone have any thoughts on what should be done in a NHD translation with these streams? What would be saved by dropping the nameless intermittent streams assuming they were simplified? The area I'm working in, (mountainous) the intermittent streams are typically spring snow melts. So until the snow melts, the streams can be sizable. It would be of concern to hikers and the forest service industry. Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What to do with unnamed NHD streams
On Oct 28, 2012, at 10:29 PM, Paul Norman wrote: From: Michal Migurski [mailto:m...@teczno.com] Sent: Sunday, October 28, 2012 8:58 PM To: OpenStreetMap US Talk Subject: Re: [Talk-us] What to do with unnamed NHD streams Does [NHD] all come in shapefile form? The simplification would be a relatively easy (though time-consuming) task for PostGIS on a server with sufficient storage, outputting new shapefiles for ogr2osm. I can help with this using one of our office servers that we use for such tasks. It comes in .mdb or .gdb form. These could be loaded into postgis and I've considered doing it. My home server has the storage and cores to do it, but I don't think it would help. The problem is you need to convert to .osm and *then* simplify. If you do this in the other order you have problems where one object intersects another (e.g. because they share a geometry for a portion of them). You end up simplifying away the intersection points and your resulting ways won't end up correctly sharing nodes. There are ways around this, by first de-duping the shared edges or nodes. Topology preservation is not terribly difficult if you prepare your data, for example by splitting lines and polygons at intersections (as in your lake example), simplifying only the parts and then reconstructing the original geometries. I would *really* like to be able to simplify prior to ogr2osm as it would dramatically decrease the size of the nodes data in-memory and decrease conversion time, I just can't see how to do it prior to processing. JOSM's simplify ways function works okay, although it doesn't deal with the case of two ways sharing nodes very well. Do you have any sample NHD extracts that might be usable for a test drive? -mike. michal migurski- m...@stamen.com 415.558.1610 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
