Re: [OSM-legal-talk] [Rebuild] Progress update
On Sat, Jun 23, 2012 at 11:05 PM, Nick Hocking nick.hock...@gmail.com wrote: I'm also a real mapper and I do truly desire the cleansing bot to weave It's magic as soon as possible. This is because I'm reluctant to add any new data to the project while there is *ANY* date left in the project that was not donated freely for the good of the project. And me (also hopefully a real mapper) - I'm still in two minds. Remapping is somewhat harder with old, tainted data in place. OTOH, the longer we wait, the less disruptive the change will be. Although last time I looked at CLEANMAP, it actually looked not too bad for Victoria (Australia) - we'd lose a couple of towns and a few suburbs around Melbourne, but nothing all that catastrophic, really. I'd definitely appreciate more frequent updates to talk@ though. (I think the issue is too important to be confined to obscure lists like osmf@ and rebuild@) Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] API not responding
On Mon, Jun 25, 2012 at 12:53 AM, Maarten Deen md...@xs4all.nl wrote: On 2012-06-25 07:12, Toby Murray wrote: According to some chatter I saw go past on IRC, ramoth (the database server) went offline for a while tonight. Admins were notified automatically and fixed it as soon as they were able. Not sure if they determined a cause before going (back?) to bed. I now also notice that the munin stats have not been updated since may 1st, so that was no indication at all. http://munin.openstreetmap.org/openstreetmap/soup.openstreetmap/index.html This is for soup, fiddlestick and bowser. These servers have been replaced by spike-01/02/03 http://wiki.openstreetmap.org/wiki/Servers Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] API not responding
On 2012-06-25 08:05, Toby Murray wrote: On Mon, Jun 25, 2012 at 12:53 AM, Maarten Deen md...@xs4all.nl wrote: On 2012-06-25 07:12, Toby Murray wrote: According to some chatter I saw go past on IRC, ramoth (the database server) went offline for a while tonight. Admins were notified automatically and fixed it as soon as they were able. Not sure if they determined a cause before going (back?) to bed. I now also notice that the munin stats have not been updated since may 1st, so that was no indication at all. http://munin.openstreetmap.org/openstreetmap/soup.openstreetmap/index.html This is for soup, fiddlestick and bowser. These servers have been replaced by spike-01/02/03 http://wiki.openstreetmap.org/wiki/Servers Ah, that explains a bit. I've changed it in the platform status too (damn those never-up-to-date wiki's). Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New Bing imagery blog post
http://www.bing.com/community/site_blogs/b/maps/archive/2012/06/25/released-our-largest-satellite-publication.aspx cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] History (Was: Re: [OpenStreetMap] Re: Hume and Hovell route)
On Fri, Jun 22, 2012 at 9:52 AM, Ian Sergeant inas66+...@gmail.com wrote: We know from the interest in historic maps, photos, etc, that this stuff is can be interesting. If I was crossing the path of significant explorer, I'd like to stop and look around. However the current framework doesn't cut it. Capturing this historical information is probably a couple of complete new schemas. Yeah, I think there really needs to be some kind of proper layering system in place to cope with historical information, and other intangible data like names. Similarly, something to deal with information that lacks a single central authority. Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Broken turn relations
Am 22.06.2012 12:52, schrieb Martin Koppenhoefer: 2012/6/21 Peter Wendorffwendo...@uni-paderborn.de: For me nodes, ways and areas sound reasonable for slipways. A slipway is similar to a street = in osm a way. It may be a very small feature and somebody may only know the estimated location = in osm a node It may be of very different width up to a wide area like = in osm a polygon/closed way. +1. Probably we should suggest to add area=yes on polygons. That shouldn't be necessary, as it's not ambiguous: A closed highway=slipway IMHO always should be interpreted as an area, so it's not necessary to add area=yes; It's no benefit to add a second tag data users have to take into account instead of requiring to take the closed-ness of the way into account. The latter variant is less error prone as mappers don't have to deal with that extra tag, and it's not less work for data consumers. regards Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 101 Overpass API
Hallo, heute gibt es gleich zwei Dinge. Roland hat über die Änderungen bei der Overpass API einen ausführlichen Blogartikel geschrieben. Und dazu ist die Wochennotiz Nr. 101 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt da: http://blog.openstreetmap.de/2012/06/wochennotiz-nr-101/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenswechsel und was passiert mit den Daten von mir?
Am 23. Juni 2012 16:50 schrieb Mike Dupont jamesmikedup...@googlemail.com: ich sage nicht das ihr die daten von kosovo nicht verwenden koennen, ihr koennt selbst euch um die lizenzen kuemmern. ich verbiete es euch nicht, ich will diese Arbeit mir nicht antun. was corine betrifft, ist doch das ganze doch das gleiche und stellt kein problem da, oder? corine ist doch Kompatible mit den neuen ODBL oder?. Es geht ja nur indirekt um die Corine Daten (die halte ich für OSM wegen des Maßstabs/Generalisierung für ungeeignet), sondern um selbstgeschöfte Daten, die technisch gesehen ggf. Nodes und Ways von dem Corine Import wiederverwendet haben und daher eine Zeit lang in wtfe aussahen, als seien sie von Löschung bedroht. Mittlerweile ist im OSMI nichts mehr rot oder gelb da, so dass ich davon ausgehe, dass nichts verloren geht. Ich glaube nicht, dass die italienische Community nach der Lizenzumstellung CORINE importieren will, bei allen Diskussionen bisher zu diesem Thema war AFAIR kaum jemals jemand dafür. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Ingenieurbüros
Am 23. Juni 2012 12:31 schrieb Jan Tappenbeck o...@tappenbeck.net: ich habe mich gerade etwas mit der Ingenieurssparte auseinander gesetzt und folgende Überlegung ist dabei herausgekommen - obwohl es schon office=architect [1] gibt: office =engineer engineer = [subtag] survey - Vermessung ... was wir brauchen oder nicht - das wäre eine endlose Diskussion und das haben wir bisher allen freigestellt. +1, da hast Du vollkommen Recht. Wenn wir so anfangen könnten wir es eigentlich gleich lassen, irgendwas einzutragen. Andererseits stimme ich auch den anderen Leuten hier im Thread zu, was das vorgeschlagene Tagging/Gruppierung angeht. Ingenieur ist nicht direkt eine Berufssparte (sondern mehrere), sondern vor allem ein (mittlerweile weitgehend veralteter) Titel in Deutschland. Ich würde nichts zusammenfassen sondern konkret den einzelnen Planer/... benennen (da gibt es dann trotzdem noch feine Unterschiede, die man bei Bedarf sub-taggen kann), also so was wie office=architect oder office=urban_planning gleich im Haupttag unterscheiden (das können zwar beides Architekten sein, aber wer z.B. ein Haus umbauen will, wird i.d.R. nicht zum urban planner wollen). Für das was in Deutschland ein Vermessungsingenieur macht gibt es z.B. verschiedene Sparten wie topographic_surveyor oder real_estate_surveyor_and_valuer, je nachdem, was derjenige macht. Falls üblich ist, dass das alles vom selben Büro aus gemacht wird, würde man eine allgemeinere Klasse wählen, z.B. office=surveyor (reines Beispiel, würde hier konkret vermutlich eher mehrere Grundklassen bilden). Welche Klassen man da am besten bildet auf englisch sollte man sich im Idealfall gemeinsam in einem (bzw. mehreren) Proposal(s) überlegen. Eine Gruppe Ingenieur (und das wäre dann eine Schublade für alles wofür es (mehr oder wenige zufällig) in Deutschland einen Ingenieurstitel gibt)) bringt uns nicht weiter und wird sich international kaum durchsetzen können, weil da die Strukturen oft anders sind, und dieses Schema daher dort nicht logisch erscheint. Ich finde es super, dass Du für diesen Bereich besser definieren willst (im OSM-tagging), wie man das taggen könnte, und finde bloß den ersten Vorschlag (office=engineer) nicht besonders gut: den Maschinenbauingenieur, den Tragwerksplaner, den Entsorgungsingenieur, den lebensmittel- technischen Ingenieur, den chemischen Ingenieur, den Tageslichtplaner, den Triebwerksingenieur alle in eine Schublade zu stecken macht keinen Sinn. Am besten entwickelt man so ein Schema Schritt für Schritt, Bereich für Bereich. Das ist schon komplex genug wenn Du nur den Vermesser angemessen berücksichtigst, wieso solltest Du Dich da nebenher noch mit den zig Spezialisierungen der chemischen Ingenieure rumschlagen müssen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Problem mit der Kuestenlinie auf Terceira
Hallo zusammen, ich berichte aus dritter Hand (Valeria besteht auf dritter ... ;-) ), habe das Problem nicht gesehen, aber das Ergebnis ist unschoen. :-( und kann auch das Problem nur mangelhaft beschreiben. Aus Zufall (weil es wir verrueckt regnet) sind wir ans Verbessern der Kuestenlinine auf Terceira gegangen. Einige SchuelerInnen hatten das sehr sehr sehr exakte gemacht und damit eine Grenze (in JOSM oder wo auch immer ... Meldung mehr als 2000) ueberschritten. Nun haben sie wohl einige Teile aus der Kuestenlinie entfernt. Wie sie das gemacht haben, weiss hier auch keiner. Danach zeigt sich folgenedes Bild. Bitte auch in JOSM betrachten. http://www.openstreetmap.org/?lat=38.7648lon=-27.0627zoom=13layers=M Danke im voraus. -- ## Manfred ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit der Kuestenlinie auf Terceira
Am 25. Juni 2012 19:02 schrieb Manfred A. Reiter ma.rei...@gmail.com: Einige SchuelerInnen hatten das sehr sehr sehr exakte gemacht und damit eine Grenze (in JOSM oder wo auch immer ... Meldung mehr als 2000) ueberschritten. Diese Grenze betrifft die Anzahl von Nodes in einem Way, derzeit 2000. Bei Küstenlinien ist das weiters kein Problem, einfach ungefähr in der Mitte (oder wo es sonst Sinn macht) in 2 oder mehr Teile teilen. (Punkt selektieren und p drücken). Das ist ja meistens sowieso keine einzelne Linie (way) sondern eine Reihe von ways hintereinander (sofern es nicht kleinere Inseln oder so sind). Wie genau man die Küstenlinien am besten mappt, ist nicht ganz klar (prinzipiell ist unser Motto wohl so genau wir können und wollen). Küstenlinien sind fraktal (je genauer man schaut, um so detaillierter und länger werden sie, theoretisch kann man jedes Sandkorn ansehen), die maximale Detaillierung wird praktisch durch die zur Verfügung stehenden Informationen vorgegeben. Allerdings ist durch die Gezeiten die AFAIK zufällig im Bild festgehaltene Position der Land-Wasser-Grenze (je nach Ort kann der Unterschied von Ebbe und Flut erheblich sein) eine sehr gute Genauigkeit wohl öfters nicht gegeben, auch wenn man viele Punkte verwendet. Bei Terceira ist das aber wohl weniger ein Problem, sieht so aus als wäre das viel Steilküste: http://www.flickr.com/photos/26034413@N04/2452135950/ da machen Gezeitenschwankungen von ungefähr einem Meter, wie man sie dort hat, praktisch nichts aus: http://tides.mobilegeographics.com/locations/161.html D.h. man kann das m.E. ruhig so präzise machen, wie man Lust hat und die Bilder hergeben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit der Kuestenlinie auf Terceira
Hallo Martin, Danke für die schnelle Antwort. Noch eine Frage ... In JOSM kann man es sehen es sind noch viele Nodes verblieben ;-) ... Gibt es eine Möglichkeit diese wieder zusammenzuführen? Grüße von der Insel. M. ## Manfred - (android) mobil - please excuse typos and brevity. Am 25.06.2012 18:46 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 25. Juni 2012 19:02 schrieb Manfred A. Reiter ma.rei...@gmail.com: Einige SchuelerInnen hatten das sehr sehr sehr exakte gemacht und damit eine Grenze (in JOSM oder wo auch immer ... Meldung mehr als 2000) ueberschritten. Diese Grenze betrifft die Anzahl von Nodes in einem Way, derzeit 2000. Bei Küstenlinien ist das weiters kein Problem, einfach ungefähr in der Mitte (oder wo es sonst Sinn macht) in 2 oder mehr Teile teilen. (Punkt selektieren und p drücken). Das ist ja meistens sowieso keine einzelne Linie (way) sondern eine Reihe von ways hintereinander (sofern es nicht kleinere Inseln oder so sind). Wie genau man die Küstenlinien am besten mappt, ist nicht ganz klar (prinzipiell ist unser Motto wohl so genau wir können und wollen). Küstenlinien sind fraktal (je genauer man schaut, um so detaillierter und länger werden sie, theoretisch kann man jedes Sandkorn ansehen), die maximale Detaillierung wird praktisch durch die zur Verfügung stehenden Informationen vorgegeben. Allerdings ist durch die Gezeiten die AFAIK zufällig im Bild festgehaltene Position der Land-Wasser-Grenze (je nach Ort kann der Unterschied von Ebbe und Flut erheblich sein) eine sehr gute Genauigkeit wohl öfters nicht gegeben, auch wenn man viele Punkte verwendet. Bei Terceira ist das aber wohl weniger ein Problem, sieht so aus als wäre das viel Steilküste: http://www.flickr.com/photos/26034413@N04/2452135950/ da machen Gezeitenschwankungen von ungefähr einem Meter, wie man sie dort hat, praktisch nichts aus: http://tides.mobilegeographics.com/locations/161.html D.h. man kann das m.E. ruhig so präzise machen, wie man Lust hat und die Bilder hergeben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit der Kuestenlinie auf Terceira
am Montag, 25. Juni 2012 um 21:41 schrieb Manfred A. Reiter: Noch eine Frage ... In JOSM kann man es sehen es sind noch viele Nodes verblieben ;-) ... Gibt es eine Möglichkeit diese wieder zusammenzuführen? Diese Frage ist ein Klassiker. Die Küstenlinien werden in der Hauptkarte (Mapnik) nicht so häufig aktualisiert, wie die übrigen Daten. Die Wasserflächen werden nur alle paar Wochen separat erstellt und mit der Karte zusammengeführt. Daher erscheinen die Änderungen in Küstenlinien nicht nicht der gewohnten Geschwindigkeit. Die Linie ist da. Man kann sie ja in JOSM sehen; außerdem erkennst Du sie auch als gestrichelte violette Grenzlinie. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt es Karte mit Anzeige von Beschränkungen wie Höhe, Länge, Gefahrgut?
Hi, such doch auf dieser Seite einfach mal nach access oder restriction. Was davon noch läuft weiß ich allerdings nicht: http://wiki.openstreetmap.org/wiki/Maps Gruß Matthias Am 23.06.2012 16:54, schrieb Bodo Meissner: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, gibt es irgendwo eine Karte, auf der Beschränkungen angezeigt werden, die für LKW relevant sind, z.B. Höhe, Breite, Länge der Fahrzeuge, Fahrverbot für LKW, Gefahrgut usw? Ich würde gern mit einem befreundeten LKW-Fahrer prüfen, ob die Daten in OSM praxistauglich sind. Mir ist klar, daß die Daten in OSM nicht vollständig sind und daß man nicht sicher auf das Fehlen von Beschränkungen in der Realität schließen kann. Vielleicht kann ich auch die Ortskenntnis der Fahrer als Datenquelle nutzen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/l2KIACgkQnMz9fgzDSqfkbQCdFobXION9gGyw5AQI61gQ7y4R 0j4Anjs4QHmvXCRPtL/NupOCIhbv75Pt =+/5y -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] reverse way e route
Devi dare ok, invertendo i tag della(/e) relazione(/i), se no spezzi il routing. Maurizio Il giorno 21 giugno 2012 15:52, emmexx emm...@tiscalinet.it ha scritto: Devo invertire il senso di una way su cui sono definite anche delle relation:route (linee tram/bus). Usando il tool di josm mi viene chiesto se voglio modificare da forward a backward. Do l'ok o devo non confermare qualcosa? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problemi con mapFactor
Ciao Tiziano Il 23/06/2012 7.15, Tiziano D'Angelo ha scritto: Più o meno ogni quanto aggiornano le mappe? Navit è forse meglio da questo punto di vista... mediamente i singoli paesi vengono aggiornati una volta al mese :-) http://navigatorfree.mapfactor.com/en/maps/ Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problemi con mapFactor
Ho provato il navigatore per un breve percorso di qualche kilometro, cambiando anche un punto intermedio, correttamente il navigatore ha ricalcolato con le varie deviazioni che ho fatto. Le indicazioni sulle rotatorie mi sono parse corrette. Solo in alcuni frangenti, dava indicazioni del tipo svoltare sulla destra quando più correttamente, sarebbe tenersi sulla destra o proseguire dritti... Devo ancora capire come impostare la navigazione per bici. Comunque mi sembra un buon programma, direi più intuitivo di OsmAnd. Ciao Tiziano Il giorno 25/giu/2012 08:56, Stefano Fraccaro stefano.fracc...@libero.it ha scritto: Ciao Tiziano Il 23/06/2012 7.15, Tiziano D'Angelo ha scritto: Più o meno ogni quanto aggiornano le mappe? Navit è forse meglio da questo punto di vista... mediamente i singoli paesi vengono aggiornati una volta al mese :-) http://navigatorfree.**mapfactor.com/en/maps/http://navigatorfree.mapfactor.com/en/maps/ Stefano __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] reverse way e route
From: Maurizio Daniele [mailto:maurizio.dani...@gmail.com] Sent: lunedì 25 giugno 2012 08:22 To: openstreetmap list - italiano Subject: Re: [Talk-it] reverse way e route Devi dare ok, invertendo i tag della(/e) relazione(/i), se no spezzi il routing. Maurizio Il giorno 21 giugno 2012 15:52, emmexx emm...@tiscalinet.it ha scritto: Devo invertire il senso di una way su cui sono definite anche delle relation:route (linee tram/bus). Usando il tool di josm mi viene chiesto se voglio modificare da forward a backward. Do l'ok o devo non confermare qualcosa? Secondo lo schema attuale, i ruoli forward e backward non vanno più usati (vedi [1]), dunque li puoi eliminare senza preoccuparti del valore. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] cambiare font size in JOSM
Come si cambia il font size per GPS waypoints (markers) sullo schermo in JOSM? E, se possibile, anche il font? C'è un parametro mappaint:fontsize, ma non sembra avere un effetto. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] reverse way e route
Direi solo e soltanto se la route è sdoppiata in due relazioni, una per ogni direzione, altrimenti si rischia di fare dei grandi pasticci! 2012/6/25 Alberto Nogaro bartosom...@yahoo.it From: Maurizio Daniele [mailto:maurizio.dani...@gmail.com] Sent: lunedì 25 giugno 2012 08:22 To: openstreetmap list - italiano Subject: Re: [Talk-it] reverse way e route Devi dare ok, invertendo i tag della(/e) relazione(/i), se no spezzi il routing. Maurizio Il giorno 21 giugno 2012 15:52, emmexx emm...@tiscalinet.it ha scritto: Devo invertire il senso di una way su cui sono definite anche delle relation:route (linee tram/bus). Usando il tool di josm mi viene chiesto se voglio modificare da forward a backward. Do l'ok o devo non confermare qualcosa? Secondo lo schema attuale, i ruoli forward e backward non vanno più usati (vedi [1]), dunque li puoi eliminare senza preoccuparti del valore. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Alveo del Po
Vorrei mappare l'alveo del Po nei dintorni della mia zona (Casale Monferrato) per poi creare delle cartine ad uso e consumo di canoisti. Sul wiki (grazie alle segnalazioni di Glaucos) ho notato che i riverbank [1] del fiume vanno posti sul punto di massimo livello del fiume (alluvioni escluse). Questo sistema taglia fuori isolette o spiagge di ghiaia (cosiddetti ghiaioni) che annualmente appaiono/scompaiono al variare del livello del fiume. Quasi tutti questi ghiaioni sono sempre nello stesso luogo, cioe' non sono sensibili alla corrente del fiume. (quantomeno non millimetricamente...) La pagina precedente del wiki, prendendo atto di questo fatto, rimanda alla proposta natural=floodplain [2]. Per segnalare (e renderizzare ad-hoc) la presenza di questi punti, io farei delle aree interne al riverbank, taggate come natural=floodplain + surface=gravel. Un esempio qui [3] Che ne pensate? Saluti Fabrizio [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank [2] http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain [3] http://www.openstreetmap.org/edit?editor=remotelat=45.15678lon=8.37293zoom=16 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alveo del Po
Il giorno 25 giugno 2012 12:05, Fabrizio Tambussa ftambu...@gmail.com ha scritto: Vorrei mappare l'alveo del Po nei dintorni della mia zona (Casale Monferrato) per poi creare delle cartine ad uso e consumo di canoisti. Sul wiki (grazie alle segnalazioni di Glaucos) ho notato che i riverbank [1] del fiume vanno posti sul punto di massimo livello del fiume (alluvioni escluse). Questo sistema taglia fuori isolette o spiagge di ghiaia (cosiddetti ghiaioni) che annualmente appaiono/scompaiono al variare del livello del fiume. Quasi tutti questi ghiaioni sono sempre nello stesso luogo, cioe' non sono sensibili alla corrente del fiume. (quantomeno non millimetricamente...) La pagina precedente del wiki, prendendo atto di questo fatto, rimanda alla proposta natural=floodplain [2]. Per segnalare (e renderizzare ad-hoc) la presenza di questi punti, io farei delle aree interne al riverbank, taggate come natural=floodplain + surface=gravel. Un esempio qui [3] Che ne pensate? Non sono d'accordissimo a segnare quelle aree. Ho l'esempio del Sesia, che vedo ogni giorno dal ponte della ferrovia e cambia conformazione da una settimana all'altra. Non parlo di variazioni millimetriche, ma di vere e proprie isole che compaiono, scompaiono, si modificano, bracci d'acqua che cambiano percorso. Nel caso del Sesia io ho mappato il riverbank fino al limite delle secche laterali, che cambiano meno delle isole, ma anche di questo non sono convintissimo... Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alveo del Po
Fabrizio Tambuzza: Questo sistema taglia fuori isolette o spiagge di ghiaia (cosiddetti ghiaioni) che annualmente appaiono/scompaiono al variare del livello del fiume. Quasi tutti questi ghiaioni sono sempre nello stesso luogo, cioe' non sono sensibili alla corrente del fiume. (quantomeno non millimetricamente...) Simone Saviolo: Non sono d'accordissimo a segnare quelle aree. Ho l'esempio del Sesia, che vedo ogni giorno dal ponte della ferrovia e cambia conformazione da una settimana all'altra. Non parlo di variazioni millimetriche, ma di vere e proprie isole che compaiono, scompaiono, si modificano, bracci d'acqua che cambiano percorso. Certo, succede in tutti i fiumi. A volte di piu` a volte di meno. Da canoista della domenica ho sempre apprezzato le cartine che indicano queste conformazioni, perche` mi aiutano a sapere dove mi trovo e aggiornare le stime dei miei tempi di percorrenza, ma anche sapere quale ramo prendere quando scendendo mi trovo un'isola che separa il corso; questo sapend benissimo che la mappa non puo` essere precisa in proposito (sia chiaro, l'isola c'e` in ogni caso, ma il ramo che si disperde in acque basse e` diverso da quello che ha sempre la sua portata). Non sono d'accordo col rifiutare l'informazione solo perche` potrebbe essere sbagliata di qualche metro (anche fossero decine di metri): l'utenza dei letti dei fiumi conosce il suo ambiente e sa fruire dell'informazione relativa. Per esempio questa rappresentazione del canarazzo non e` sbagliama: http://osm.org/go/0Cg6Ni11 ma potrebbe essere piu` utile mostrare a chi risale che il ramo interno potrebbe essere cieco: http://binged.it/MvhfQY /alessandro ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
Il giorno 24 giugno 2012 18:46, Alexander Roalter alexan...@roalter.it ha scritto: On 06/24/2012 05:51 PM, Paolo Pozzan wrote: Mi sembra però strano che non ci sia nessuno spartitraffico... In quel caso sarebbe necessario sdoppiare le vie passanti per il casello e le relazioni diminuirebbero. Paolo P. Io consiglierei disegnare le vie che entrano i caselli separate per ogni direzione (ma non una linea per ogni casello, come è fatto a Vercelli). Così serve solo una relazione dopo il casello, come nell'immagine attaccata: Temo che entrambi i modi abbiano vantaggi e svantaggi. - Disegnando tutte le corsie, sappiamo quante sono le corsie. D'altro canto, non è possibile stabilire a priori quali sono riservate all'entrata e quali all'uscita. Tuttavia, questo ci permette di taggare le corsie riservate al telepass o di indicare su ogni corsia i servizi disponibili (contante, viacard, telepass). Infine, in certi caselli (es. barriera ovest di Milano) bisogna scegliere la corsia in base alla direzione da seguire: se entro in una certa corsia ad esempio posso andare verso Varese ma non verso Bologna. Per indicare questo dobbiamo indicare ogni corsia. - Disegnandone solo una per senso di marcia, il mapping è più semplice (ma meno raffinato), non c'è il problema di quante corsie siano aperte in un senso o nell'altro, ma non possiamo indicare tutte le altre informazioni. Per questo, preferisco segnare tutte le corsie. Quelle interessanti (es. telepass) sono sempre nella stessa direzione di norma. Un'altra domanda: alcune volte ho visto che motorway_link c'è solo fino al casello, poi continua primary_link fino all'ingresso alla prossima primary... Ma io penso che è meglio motorway_link fino alla primary. Cosa pensate? Proprio il caso di Vercelli :-) A Vercelli Ovest avevo messo motorway fino all'uscita sulla statale, a Vercelli Est invece ho messo primary anche fino al casello. In effetti mi sembra più corretto mettere motorway fino allo sbocco sulla viabilità ordinaria. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
Il giorno 24 giugno 2012 18:38, Alexander Roalter alexan...@roalter.it ha scritto: e un'altra cosa: ho trovato delle correzioni sbagliati (almeno come lo vedo io). Per esempio relazione 2249165, che usa no_left_turn invece di 'only_straight_on'). Come potete vedere nell'immagine attaccata. Sistemare? Lasciare? O non è sbagliato? Lasciare, perché non è sbagliato. Mi ero già lamentato del fatto che le restrizioni erano inutilmente dettagliate, ed eccone la dimostrazione. Se la relazione coinvolge quelle due way, allora indica un divieto. Per qualunque software utilizzatore non è neanche interessante sapere se è un divieto di svolta a sinistra o destra o di prosecuzione: gli basta sapere che da qui a qui si è obbligati ad andare (o è vietato andare). Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alveo del Po
Il 25 giugno 2012 12:35, Alessandro Rubini rubini-l...@gnudd.com ha scritto: ma potrebbe essere piu` utile mostrare a chi risale che il ramo interno potrebbe essere cieco: http://binged.it/MvhfQY Infatti, tutta la zona interna al curvone del Ticino la taggherei come ghiaione allagabile. Quando faro' il rendering, il canoista capira' dove l'acqua e' piu' profonda e dove potrebbe esserci un'isola/ghaione poco sotto la chiglia. E gia' che ci siamo, come si possono taggare i muraglioni di blocchi di cemento anti-erosione sul lato esterno della curva? Saluti Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alveo del Po
Il giorno 25/giu/2012, alle ore 12.05, Fabrizio Tambussa ha scritto: Per segnalare (e renderizzare ad-hoc) la presenza di questi punti, io farei delle aree interne al riverbank, taggate come natural=floodplain + surface=gravel. Non è il tag giusto. Da quanto ho capito, natural=floodplain dovrebbe servire a rappresentare aree esterne all'alveo del fiume, destinate ad essere sommerse in occasione di piene che superano la portata di piena ordinaria. Nel caso del Po, è più o meno la definizione dell'area golenale delimitata dagli argini maestri. Concordo comunque che si dovrebbe trovare il modo di rappresentare i dettagli dell'alveo di un fiume in regime di magra... è vero che si tratta di elementi poco stabili, e che quindi richiederebbero un aggiornamento continuo, ma per un progetto come OSM questo non è un problema, magari è uno stimolo in più. E poi, i ghiaioni, le isolette e i canali di magra si vedono in tutte le carte topografiche; perché non ci dovrebbero essere su OSM? Saluti, Guido ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
2012/6/22 Groppo O grop...@gmail.com: Il giorno 22 giugno 2012 18:58, Alexander Roalter alexan...@roalter.it ha scritto: Am 22.06.2012 17:28, schrieb Sky One: Ciao, ho trovato un falso positivo: http://www.openstreetmap.org/browse/nodeancora/252474666 Mi puoi dire cosa non è giusto? ho inserito una restriction andando dal way 168553986 verso il nodo 1798000467, dove è possibile solo andare dritto, ma non fare il torno a sinistra per la way 42774325. Forse intendeva dire che la mia pagina segnava il nodo come sbagliato mentre non lo è (ma perché tu nel frattempo l'hai corretto). La pagina segnava ancora l'errore perché doveva essere aggiornata (lo ho appena fatto). Grazie per aver capito ciò che intendevo. Scusate, ma mi era sfuggita questa parte del thread... :-/ -- Cià Cristiano / Sky One Home: http://www.skyone.it (itinerari in moto e non solo) Pensieri: http://blog.skyone.it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: PCN 2006 Italia
...senza aprire nuovi post ...ultimamente pure io non riesco ad aprire il pcn con la comparsa dei fastidiosi riquadri rosi...??? -- View this message in context: http://gis.19327.n5.nabble.com/PCN-2006-Italia-tp5712002p5714110.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
Am 25.06.2012 12:42, schrieb Simone Saviolo: Il giorno 24 giugno 2012 18:46, Alexander Roalter alexan...@roalter.it mailto:alexan...@roalter.it ha scritto: On 06/24/2012 05:51 PM, Paolo Pozzan wrote: Mi sembra però strano che non ci sia nessuno spartitraffico... In quel caso sarebbe necessario sdoppiare le vie passanti per il casello e le relazioni diminuirebbero. Paolo P. Io consiglierei disegnare le vie che entrano i caselli separate per ogni direzione (ma non una linea per ogni casello, come è fatto a Vercelli). Così serve solo una relazione dopo il casello, come nell'immagine attaccata: Temo che entrambi i modi abbiano vantaggi e svantaggi. - Disegnando tutte le corsie, sappiamo quante sono le corsie. D'altro canto, non è possibile stabilire a priori quali sono riservate all'entrata e quali all'uscita. Tuttavia, questo ci permette di taggare le corsie riservate al telepass o di indicare su ogni corsia i servizi disponibili (contante, viacard, telepass). Infine, in certi caselli (es. barriera ovest di Milano) bisogna scegliere la corsia in base alla direzione da seguire: se entro in una certa corsia ad esempio posso andare verso Varese ma non verso Bologna. Per indicare questo dobbiamo indicare ogni corsia. Se ci sono corsie riservate al telepass (e sono taggate così), allora è ragionevole mettere delle linee separate. Nel altro caso, c'è anche il tag lanes=*. Se per esempio c'è una casella con dieci entrate, e ci sono tre corsie (una all'entrata, due all'uscita) telepass, userei 4 way, due taggate con telepass (una con lanes=1, l'altra con lanes=2), e le altre sette corsie nelle rimanenti due way, uno taggato con lanes=3, e l'altro con lanes=4. Se succede che l'associazione con entrata/uscita non è fissa, occorrebbe usare lo stesso metodo come usato per le corsie unidirezionali condizionali... non so che tagging è usato per queste. - Disegnandone solo una per senso di marcia, il mapping è più semplice (ma meno raffinato), non c'è il problema di quante corsie siano aperte in un senso o nell'altro, ma non possiamo indicare tutte le altre informazioni. se ci sono informazioni diversi, allora prendere un way per ognuna informazione (telepass/no telepass, entrata/uscita, solo camion, solo moto...), ma altrimenti lo eviterei. Per questo, preferisco segnare tutte le corsie. Quelle interessanti (es. telepass) sono sempre nella stessa direzione di norma. Un'altra domanda: alcune volte ho visto che motorway_link c'è solo fino al casello, poi continua primary_link fino all'ingresso alla prossima primary... Ma io penso che è meglio motorway_link fino alla primary. Cosa pensate? Proprio il caso di Vercelli :-) A Vercelli Ovest avevo messo motorway fino all'uscita sulla statale, a Vercelli Est invece ho messo primary anche fino al casello. In effetti mi sembra più corretto mettere motorway fino allo sbocco sulla viabilità ordinaria. +1 -- cheers, Alex -- cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
2012/6/25 Simone Saviolo simone.savi...@gmail.com: Io consiglierei disegnare le vie che entrano i caselli separate per ogni direzione (ma non una linea per ogni casello, come è fatto a Vercelli). Per questo, preferisco segnare tutte le corsie. +1 visto che ci sono delle separazioni fisici è scoretto (un po') di non farlo. Comunque servono a poco secondome e quindi per il momento lo ritengo di importanza talmente bassa che non lo faccio. Un'altra domanda: alcune volte ho visto che motorway_link c'è solo fino al casello, poi continua primary_link fino all'ingresso alla prossima primary... Ma io penso che è meglio motorway_link fino alla primary. Cosa pensate? sono purista: l'inizio dell'autostrada è di solito segnalato e da lì in poi vale motorway_link / motorway. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: PCN 2006 Italia
2012/6/25 scratera piz...@alice.it: ...senza aprire nuovi post ...ultimamente pure io non riesco ad aprire il pcn con la comparsa dei fastidiosi riquadri rosi...??? mi sa che ne hai abusato... se hai un ip dinamico stacca e riattacca la presa della corrente, altrimenti contatta il PCN e chiedi di essere rimosto dalla black list -- View this message in context: http://gis.19327.n5.nabble.com/PCN-2006-Italia-tp5712002p5714110.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Svincoli autostradali senza restriction
2012/6/25 Alexander Roalter alexan...@roalter.it: Se ci sono corsie riservate al telepass (e sono taggate così), allora è ragionevole mettere delle linee separate. Nel altro caso, c'è anche il tag lanes=*. lanes non è adatto (strettamente), perchè non è per carreggiate ma per corsie. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag alternativo a surface
2012/6/23 emmexx emm...@tiscalinet.it: Forse per tag privati è meglio usare un namespace (per una volta tanto il concetto è giusto...) privato? Es. it:fiab:surface=xxx Preferirei non gestirlo come un tag privato. La descrizione di una superficie non dovrebbe essere una questione di fiab o di altri. E' vero che la descrizione di una superficie non è una questione privata, ma il suo utilizzo automatico da parte di un software sì. Penso ad esempio a http://wiki.openstreetmap.org/wiki/Key:osmc:symbol I simboli disponibili sono un set limitato e non aperto ad ulteriori inclusioni (http://www.wanderreitkarte.de/symbols_en.html) Invece il tag surface, per sua natura, invita ad una descrizione precisa della natura della superficie, e a mio parere mal si presta ad un utilizzo da parte di un router (come trattare i valori ignoti?) Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Presentazione e dubbi iniziali
Innanzitutto mi presento: mi chiamo Antonio e da poco ho iniziato a contribuire attivamente a OSM. (e cercherò di imparare in fretta in modo da correggere il prima possibile gli errori che ho fatto e farò). Ho due dubbi riguardo alle zone in cui vivo e su cui stò lavorando: 1 - usando JOSM, ho visto che le foto provenienti da Bing e Pcn non sono allineate: o quanto meno non lo sono a Castelleone (Cr) dove sono sfalsate di qualche metro a qualsiasi ingrandimento. Di chi mi devo fidare? 2 - vorrei cambiare degli edifici di Milano sbagliati (ad esempio Via Giovanni Milani lato destro); questi riportano come tag: source:Regione Lombardia - La banca dati territoriali CTR1 è prodotta da Regione Lombardia - Infrastruttura per l'Informazione Territoriale. A intuito direi che se cambio l'edificio a quel punto devo anche togliere la fonte, ho ragione o sbaglio? Grazie mille Antonio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Motorway e motorway_link senza oneway=*
In data lunedì 25 giugno 2012 23:08:30, Groppo O ha scritto: Siete d'accordo ad aggiungere a tutte il oneway=* corretto? OK per le motorway, ma non per le motorway_link. Alla seconda categoria appartengono anche tratti di svincoli in entrata/uscita con corsie a doppio senso di marcia non separate da alcuna barriera fisica (guard rail piuttosto che cordoli o aiuole o New Jersey). Ciao Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag alternativo a surface
Il 06/25/2012 10:15 PM, Federico Cozzi scrisse: Invece il tag surface, per sua natura, invita ad una descrizione precisa della natura della superficie, e a mio parere mal si presta ad un utilizzo da parte di un router (come trattare i valori ignoti?) Non sono d'accordo. La precisione si puo' ottenere comunque procedendo per classi. Nel caso milanese non e' fondamentale definire valori diversi per i vari pave' e autobloccanti. Ma si puo' raggruppare tutto con delle gerarchie. Partendo da zero si sarebbe potuto fare (faccio un esempio banale e non esaustivo): paved paved:asphalt paved:asphalt:draining paved:concrete paved:sett paved:cobblestone ... unpaved ... Ovviamente adesso e' tutto piu' complicato. Secondo me e' sbagliato lasciare la pagina wiki cosi' come e' ora. Si spinge sostanzialmente ad inserire valori che piu' si adattano alla propria situazione, senza considerazioni relative a rendering e routing. Ovvio che chi si trova a sviluppare un software ad un certo punto deve chiudere ed applicare delle regole. Il fatto che surface sia un po' incasinato non deve essere necessariamento un motivo per continuare cosi'. Ogni tanto specifiche e protocolli cambiano, si spera in meglio, ed i software si adattano. Certo che finche' si insiste nel lasciare le cose come stanno, anche se sono sconclusionate, perche' altrimenti i software smettono di funzionare, non si andra' molto lontano. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Presentazione e dubbi iniziali
2012/6/25 antonio.iacchetti antonio.iacche...@excite.it: 1 - usando JOSM, ho visto che le foto provenienti da Bing e Pcn non sono allineate: o quanto meno non lo sono a Castelleone (Cr) dove sono sfalsate di qualche metro a qualsiasi ingrandimento. Di chi mi devo fidare? PCN di solito è molto piu' preciso di Bing. Io di solito mi fido delle tracce GPX esistenti in zona e cerco di fare l'allineamento usando quelle come riferiemento. 2 - vorrei cambiare degli edifici di Milano sbagliati (ad esempio Via Giovanni Milani lato destro); questi riportano come tag: source:Regione Lombardia - La banca dati territoriali CTR1 è prodotta da Regione Lombardia - Infrastruttura per l'Informazione Territoriale. A intuito direi che se cambio l'edificio a quel punto devo anche togliere la fonte, ho ragione o sbaglio? Togli pure... -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Presentazione e dubbi iniziali
Ciao e ben venuto e buon mapping nel cremonese:) da fare ce nè molto per evitare di fare gli errori che pure io ho fatto all'inizio le nuove ortofoto bing sono buone le vecchie che usavo pure io ahimè sono molto discostanti e fuorvianti per cui meglio il Pcn gli edifici riportati sono antichi in molte zone abbattuti e rifatti o sostituiti da centri commerciali ecc per cui se è errato correggilo pure:) ciao Messaggio originale Da: antonio.iacche...@excite.it Data: 25/06/2012 23.13 A: talk-it@openstreetmap.org Ogg: [Talk-it] Presentazione e dubbi iniziali Innanzitutto mi presento: mi chiamo Antonio e da poco ho iniziato a contribuire attivamente a OSM. (e cercherò di imparare in fretta in modo da correggere il prima possibile gli errori che ho fatto e farò). Ho due dubbi riguardo alle zone in cui vivo e su cui stò lavorando: 1 - usando JOSM, ho visto che le foto provenienti da Bing e Pcn non sono allineate: o quanto meno non lo sono a Castelleone (Cr) dove sono sfalsate di qualche metro a qualsiasi ingrandimento. Di chi mi devo fidare? 2 - vorrei cambiare degli edifici di Milano sbagliati (ad esempio Via Giovanni Milani lato destro); questi riportano come tag: source:Regione Lombardia - La banca dati territoriali CTR1 è prodotta da Regione Lombardia - Infrastruttura per l'Informazione Territoriale. A intuito direi che se cambio l'edificio a quel punto devo anche togliere la fonte, ho ragione o sbaglio? Grazie mille Antonio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Re: Motorway e motorway_link senza oneway=*
Messaggio originale Da: klava...@gmail.com Data: 25/06/2012 23.17 A: talk-it@openstreetmap.org Ogg: Re: [Talk-it] Motorway e motorway_link senza oneway=* In data lunedì 25 giugno 2012 23:08:30, Groppo O ha scritto: Siete d'accordo ad aggiungere a tutte il oneway=* corretto? OK per le motorway, ma non per le motorway_link. Alla seconda categoria appartengono anche tratti di svincoli in entrata/uscita con corsie a doppio senso di marcia non separate da alcuna barriera fisica (guard rail piuttosto che cordoli o aiuole o New Jersey). Ciao Alessio In quel caso dipende da svincolo a svincolo e si inserisce il oneway solo alla fine Ho trovato alcuni casi in cui c'erano delle service per le fabbriche per cui secondo me bisogna valutare caso per caso ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Motorway e motorway_link senza oneway=*
2012/6/25 Milani Alessio klava...@gmail.com: Siete d'accordo ad aggiungere a tutte il oneway=* corretto? OK per le motorway, ma non per le motorway_link. Alla seconda categoria Al contrario, a me oneway=* sembra utile proprio per le motorway_link, proprio perché non si sa in generale se sono a senso unico o a doppio senso. Aggiungere oneway=yes (oppure no a seconda dei casi) sembra un'ottima cosa. Viceversa lo ritengo meno utile per le motorway, perché autostrade a doppio senso non ne ho ancora viste... Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag alternativo a surface
2012/6/25 emmexx emm...@tiscalinet.it: Partendo da zero si sarebbe potuto fare (faccio un esempio banale e non esaustivo): paved paved:asphalt paved:concrete ... unpaved ... Siamo d'accordo anche se diciamo cose diverse. :-) Io sono per tenere il tag surface così com'è (cioè a formato libero) e per aggiungere un nuovo tag a valori limitati che possa essere gestito via software. Anni fa proposi su questa lista di introdurre il tag paved=yes/no (http://lists.openstreetmap.org/pipermail/talk-it/2009-May/007740.html) anche se poi la proposta è rimasta nel dimenticatoio... Tu sostieni di strutturare i valori del tag surface= organizzando in maniera gerarchica i tipi di superficie, e in particolare suddividendoli tra paved e unpaved. Penso che il risultato sarebbe all'incirca lo stesso ... Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Fwd: [OSM-talk] New Bing imagery blog post
nuove immagini bing disponibili per OSM. -- Forwarded message -- From: Richard Fairhurst rich...@systemed.net Date: Tue, Jun 26, 2012 at 12:17 AM Subject: [OSM-talk] New Bing imagery blog post To: t...@openstreetmap.org http://www.bing.com/community/site_blogs/b/maps/archive/2012/06/25/released-our-largest-satellite-publication.aspx cheers Richard ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Motorway e motorway_link senza oneway=*
Il 25/06/2012 23:59, Federico Cozzi ha scritto: 2012/6/25 Milani Alessioklava...@gmail.com: Siete d'accordo ad aggiungere a tutte il oneway=* corretto? OK per le motorway, ma non per le motorway_link. Alla seconda categoria Al contrario, a me oneway=* sembra utile proprio per le motorway_link, proprio perché non si sa in generale se sono a senso unico o a doppio senso. Aggiungere oneway=yes (oppure no a seconda dei casi) sembra un'ottima cosa. +1 Viceversa lo ritengo meno utile per le motorway, perché autostrade a doppio senso non ne ho ancora viste... Una volta esistevano; ora non so se siano state abolite (in Italia). In ogni caso OSM è un progetto internazionale, quindi per me è meglio aggiungere comunque il tag. Male non fa. Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bologna e Bari
Leggo solo ora questa discussione di qualche mese fa. Il 08/04/2012 21:17, alberto ha scritto: Il 06/04/2012 3.05, Simone Cortesi ha scritto: 2012/4/5 Maurizio Napolitanonapoo...@gmail.com: http://dati.comune.bologna.it/ http://dati.comune.bari.it/ non so voi, ma io la pagina di Bari nemmeno la riesco a caricare. Ne firefox 11 ne chrome (sotto Linux) me la caricano. Tutti gli add-on disattivati. Quella di Bologna invece funziona. Ci sono diverse cose interessanti, compresi i numeri civici di tutto il comune, già caricati su OSM. più veloci di così Che bello... davvero ottima notizia! Solo un appunto: ho notato che bisognerebbe rimettere mano a praticamente tutti i civici inseriti. http://tools.geofabrik.de/osmi/?view=addresseslon=11.34033lat=44.49121zoom=14overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads Io sono un fan della relazione street; voi avete invece usato addr:street. Niente di grave, se non fosse che il valore l'avete scritto tutto maiuscolo, mentre per funzionare correttamente dovrebbe essere IDENTICO al valore del tag name. Buon mapping! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-lt] Bing nuotraukos
Sveiki Bing nuotraukų atnaujinimo dienoraščio įrašas: http://www.bing.com/community/site_blogs/b/maps/archive/2012/06/25/released-our-largest-satellite-publication.aspx Įdomi pastraipa: „As of today the Global Ortho project is 85% acquired and published. Just this month, Bing Imagery Technologies hit a significant milestone by completing 100% of aerial photography over the United States. The photography in Europe is slated to be finished by this fall and all updated imagery should be published by the end of 2012.“ Įdomu, ar Lietuva patenka į tą „Europą“, kuri iki rudens turi būti 100% padengta... -- Tomas Straupis ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
[Talk-se] Västervik
Glad sommar på er! Just hemkommen efter midsommarfirande i Västervik. Situationen vad gäller OSM-data för Västervik är hemsk, till stor del säkert pga att Bing saknar vettiga bilder över området. Jag försöker i alla fall kartlägga vad jag hinner när jag är där, vilket blir ett par gånger om året. Den här gången blev det kanske 20-30 gator och cykelvägar, däribland en ny rondell på stora infartsvägen som fortfarande saknas i Google Maps ( http://osm.org/go/0Y6kvOy1W- ). Om någon av er ska till Västervik i sommar, ta gärna med er en cykel och hoja runt lite och kartlägg - det saknas fortfarande väldigt många gator, särskilt i norra och västra delarna. /Fredrik ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-es] Google lanza la navegación sin GPS
Hola; No se si conocéis el proyecto de Google para navegación sin GPS http://www.google.com/enterprise/mapsearth/products/coordinate.html Google pone su gran poder ecónomico de manifiesto otra vez. No hay que olvidar que para que esto funcione se necesita una colaboración ciudadana. En Alemania dudo que lo puedan hacer, sobretodo después de la sentencia por recoger datos privados de las wifis. Esta forma de trabajar abre un dilema, si google quiere cobrar por este servició basado en la localización de las wifis privadas y públicas. El servicio es de Google pero las wifis son privadas. Dejo en el aire el debate. Aunque me creo que la UE va ha estar vigilando de cerca. En mi opinión algo al estilo de OSM podría ser una solución. Ciudadanos que registran la posición de sus wifis en un sistema abierto donde terceros pueden crear servicios abiertos o privativos. Esto favorece la participación ciudadana y el que mas iniciativas puedan sacar un provecho y no tan solo el mega-gigante Google que se lo comería todo. Lanzo una idea de proyecto. Localización de wifis en OSM para la creación de servicios de localización abiertos sin GPS. -- Pau Aragó Galindo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
El Lunes, 25 de junio de 2012, Pau Aragó escribió: Hola; No se si conocéis el proyecto de Google para navegación sin GPS http://www.google.com/enterprise/mapsearth/products/coordinate.html Google pone su gran poder ecónomico de manifiesto otra vez. No hay que olvidar que para que esto funcione se necesita una colaboración ciudadana. En Alemania dudo que lo puedan hacer, sobretodo después de la sentencia por recoger datos privados de las wifis. Esta forma de trabajar abre un dilema, si google quiere cobrar por este servició basado en la localización de las wifis privadas y públicas. El servicio es de Google pero las wifis son privadas. Dejo en el aire el debate. Aunque me creo que la UE va ha estar vigilando de cerca. Ah no, si van a cobrar por mi wifi que me paguen. A ver si vamos a ponernos tontos y a intercambiar routers de diferentes sitios de la ciudad (o de diferentes ciudades). En mi opinión algo al estilo de OSM podría ser una solución. Ciudadanos que registran la posición de sus wifis en un sistema abierto donde terceros pueden crear servicios abiertos o privativos. Esto favorece la participación ciudadana y el que mas iniciativas puedan sacar un provecho y no tan solo el mega-gigante Google que se lo comería todo. Lanzo una idea de proyecto. Localización de wifis en OSM para la creación de servicios de localización abiertos sin GPS. Creo que algo así lo veo más factible. Aunque esto sigue siendo útil sólo parcialmente, para zonas muy pobladas y posiciones poco exactas (ya sabemos que la señal de la wifi puede variar mucho con el clima, con mover el router a otra habitación,...). -- María Arias de Reyna Domínguez Consultora GIS Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 670 41 98 62 Fax: +34 954 51 64 73 www.emergya.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
El 25 de junio de 2012 09:24, Maria Arias de Reyna mar...@emergya.comescribió: El Lunes, 25 de junio de 2012, Pau Aragó escribió: Hola; No se si conocéis el proyecto de Google para navegación sin GPS http://www.google.com/enterprise/mapsearth/products/coordinate.html Google pone su gran poder ecónomico de manifiesto otra vez. No hay que olvidar que para que esto funcione se necesita una colaboración ciudadana. En Alemania dudo que lo puedan hacer, sobretodo después de la sentencia por recoger datos privados de las wifis. Esta forma de trabajar abre un dilema, si google quiere cobrar por este servició basado en la localización de las wifis privadas y públicas. El servicio es de Google pero las wifis son privadas. Dejo en el aire el debate. Aunque me creo que la UE va ha estar vigilando de cerca. Ah no, si van a cobrar por mi wifi que me paguen. A ver si vamos a ponernos tontos y a intercambiar routers de diferentes sitios de la ciudad (o de diferentes ciudades). En mi opinión algo al estilo de OSM podría ser una solución. Ciudadanos que registran la posición de sus wifis en un sistema abierto donde terceros pueden crear servicios abiertos o privativos. Esto favorece la participación ciudadana y el que mas iniciativas puedan sacar un provecho y no tan solo el mega-gigante Google que se lo comería todo. Lanzo una idea de proyecto. Localización de wifis en OSM para la creación de servicios de localización abiertos sin GPS. Creo que algo así lo veo más factible. Aunque esto sigue siendo útil sólo parcialmente, para zonas muy pobladas y posiciones poco exactas (ya sabemos que la señal de la wifi puede variar mucho con el clima, con mover el router a otra habitación,...). -- María Arias de Reyna Domínguez Consultora GIS Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 670 41 98 62 Fax: +34 954 51 64 73 www.emergya.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ¿Y qué dispositivo no trae ya GPS? Creo que llegan un poco tarde. -- Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
¿Y qué dispositivo no trae ya GPS? Creo que llegan un poco tarde. Por ejemplo mi móvil no tiene GPS cuando estoy dentro de un centro comercial, trabajando en la oficina (la mayor parte del día), en el coche (si no lo tengo en el salpicadero), etc. etc. Gari ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
El 25 de junio de 2012 09:11, Pau Aragó sani...@gmail.com escribió: En mi opinión algo al estilo de OSM podría ser una solución. Ciudadanos que registran la posición de sus wifis en un sistema abierto donde terceros pueden crear servicios abiertos o privativos. Esto favorece la participación ciudadana y el que mas iniciativas puedan sacar un provecho y no tan solo el mega-gigante Google que se lo comería todo. Lanzo una idea de proyecto. Localización de wifis en OSM para la creación de servicios de localización abiertos sin GPS. Algo parecido existe: WIGLE [1]. Aunque no me queda claro su licencia [2] [1] http://wigle.net/gps/gps/main [2] https://wigle.net/gps/gps/main/faq/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
El Monday 25 June 2012 10:18:27 David va escriure: ¿Y qué dispositivo no trae ya GPS? Creo que llegan un poco tarde. La principal utilidad de estos sistemas es que te permiten tener una solucion de tu posicion (usando el gps) en menos de 20 segundos (si dispones de un Almanac valido y una posicion estimada con un error menor de 2km ) o de 10 segundos si tienes Ephemeris validas. Y ademas permite a google saber donde estas legalmente. Tambien hay alternatavias mas libres como http://www.openwlanmap.org/?lang=en ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Google lanza la navegación sin GPS
On Mon, Jun 25, 2012 at 09:11:34AM +0200, Pau Aragó wrote: Hola; No se si conocéis el proyecto de Google para navegación sin GPS http://www.google.com/enterprise/mapsearth/products/coordinate.html En mi opinión algo al estilo de OSM podría ser una solución. Ciudadanos que registran la posición de sus wifis en un sistema abierto donde terceros pueden crear servicios abiertos o privativos. http://openbmap.org/ -- Celso González (PerroVerd) http://mitago.net ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ar] aburrido? Nunca más!
Esto encontré en un RSS pero no anda el link, así que les paso la descripción. Supongo que es la explicación a las nuevas imágenes de las que hablaron. http://www.bing.com/community/Site_Blogs/b/maps/archive/2012/06/25/released-our-largest-satellite-publication.aspx Today we’re thrilled to announce the publication of our largest satellite release to date. In fact, this release is larger than all of our past Aerial releases combined! The latest Aerial release includes new Satellite imagery as well as Global Ortho photography. Both releases total 165 terabytes of new data live on Bing Maps. Prior to this, our existing Aerial footprint was 129 terabytes total. AERIAL: HIGH-RESOLUTION NADIR OR STRAIGHT DOWN ORTHOPHOTOS TAKEN BY AIRCRAFT OR SATELLITE De: Werner Horsch werner.hor...@gmail.com Para: mggime...@i-nis.com.ar CC: talk-ar@openstreetmap.org Enviado: domingo, 24 de junio de 2012 18:52 Asunto: Re: [Talk-ar] aburrido? Nunca más! gpor ahí ya existen trazas GPS del lugar, las podes descargar con JOSM si es q existen. Si no se dibuja corrido y luego se acomoda. Ya dibuje ciudades enteras sin imagenes y cuando aparecieron el error era un desplazamiento de unos 10 a 20m 2012/6/20 Martin Andrés Gomez Gimenez mggime...@i-nis.com.ar El mié, 20-06-2012 a las 10:17 -0300, Werner Horsch escribió: seguramente lo dice por nosotros no por él Martín Las imagenes de Bing están desplazadas fuera de GBA, correrlas después es fácil A ver si entiendo, la idea es usar estas imagenes corridas y después en algún momento corregirlas con trazas GPSs? Hace un tiempo atrás entre en contacto con el Dpto de Geodesia de la Pcia de BA, para ver el tema de la licencia de sus imagenes satelitales si las podiamos usar en caso de comprarlas. Lamentablemente nunca me respondieron, el día q tenga q ir por laburo preguntaré personalmente Buenísimo! -- Martin Andres Gomez Gimenez web: http://www.i-nis.com.ar e-mail: mggime...@i-nis.com.ar Jabber: mggime...@i-nis.com.ar Usuario Linux: #306000 ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
[Talk-at] Wienerwald (relation 305434)
Hallo! Irgendwer hatte wieder mal den Wienerwald (konkret Relation 305434) zerstört... ich hab' ihn wieder geschlossen, aber die Gegend um Haitzawinkel ist noch verbesserungswürdig. Wobei das bitte wer machen sollte, der bissl Übung mit sowas hat... /al http://www.openstreetmap.org/?lat=48.18236lon=16.05852zoom=16layers=Mrelation=305434 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
On 25.06.2012 13:31, Andreas Labres wrote: Irgendwer hatte wieder mal den Wienerwald (konkret Relation 305434) zerstört... ich hab' ihn wieder geschlossen, aber die Gegend um Haitzawinkel ist noch verbesserungswürdig. Wobei das bitte wer machen sollte, der bissl Übung mit sowas hat... Was genau ist bei Haitzawinkel falsch? Sieht für mich ok aus. Aber ein paar Sachen sind mir aufgefallen, hauptsächlich an Relation 919063. An der ist einiges kaputt, ich bin grad am Korrigieren. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
On 26.06.12 00:18, Friedrich Volkmann wrote: Was genau ist bei Haitzawinkel falsch? Ich hatte den Waldrand ursprünglich quer unter die residential Fläche gelegt. Jetzt isser mitten auf der Haitzawinkelstraße, was auch suboptimal ist... Außerdem ist die Gegend dort überhaupt sehr viel Wiese, auch wenn dort viele Einfamilienhäuser gewachsen sind in den letzten Jahren. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-lv] Nez kur te būtu jālabo?
Šajā gadījumā es uzskatu, ka ir jāpārveido par service, bet uz rietumiem pie Statoil vajadzētu samazināt ielas nozīmību, lai ir kā V16. Vēl arī izskatās, ka ir sačakarēts viadukts uz lidostu. Tur tilti izskatās, ka ir nevietā. 2012/6/25 Janis Elmeris janis.elme...@intelligentsystems.lv Te arī dīvaini izmaršrutē, lai gan labāk taču braukt taisni: http://map.project-osrm.org/KJ Jānis On 2012.06.24. 21:45, Gints Polis wrote: Ir pāris routingi kuri saka braukt lejā no pārvada... http://map.project-osrm.org/KD kaut kā stulbi :). -- Ginc ___ Talk-lv mailing listTalk-lv@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Es ar tikko ieraudzīju. Nu arī man tas šķiet jau par traku. 2012/6/25 Viesturs Zarins viest...@gmail.com Sveicins! Jāņoju Jāņoju, skatos Rīgā tilti jaunu parādījušies. Manliekas ka nupat sāk par traku paliikt - plānoto tiltu jau tikpat cik īsto. No vienas puses jau skaisti - sabiedrībai parādīt kādi varianti ir iecerēti. No otras puses baigais juceklis sanāk. Viesturs ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Kādā ziņā juceklis? Man vizuāli vismaz OSM pamatdizainā plānotie tilti liekas ļoti labi nodalīti no reālajiem tiltiem. Jānis On 2012.06.25. 12:46, Jānis Ročāns wrote: Es ar tikko ieraudzīju. Nu arī man tas šķiet jau par traku. 2012/6/25 Viesturs Zarins viest...@gmail.com mailto:viest...@gmail.com Sveicins! Jāņoju Jāņoju, skatos Rīgā tilti jaunu parādījušies. Manliekas ka nupat sāk par traku paliikt - plānoto tiltu jau tikpat cik īsto. No vienas puses jau skaisti - sabiedrībai parādīt kādi varianti ir iecerēti. No otras puses baigais juceklis sanāk. Viesturs ___ Talk-lv mailing list Talk-lv@openstreetmap.org mailto:Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Pārāk daudz informācijas jau saucās SPAMS! Un kurā datumā plānos šos tiltus būvēt? Kur ir norādīts source? Jādzēš ārā šie tilti! 2012/6/25 Janis Elmeris janis.elme...@intelligentsystems.lv Kādā ziņā juceklis? Man vizuāli vismaz OSM pamatdizainā plānotie tilti liekas ļoti labi nodalīti no reālajiem tiltiem. Jānis On 2012.06.25. 12:46, Jānis Ročāns wrote: Es ar tikko ieraudzīju. Nu arī man tas šķiet jau par traku. 2012/6/25 Viesturs Zarins viest...@gmail.com Sveicins! Jāņoju Jāņoju, skatos Rīgā tilti jaunu parādījušies. Manliekas ka nupat sāk par traku paliikt - plānoto tiltu jau tikpat cik īsto. No vienas puses jau skaisti - sabiedrībai parādīt kādi varianti ir iecerēti. No otras puses baigais juceklis sanāk. Viesturs ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing listTalk-lv@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Jādzēš ārā šie tilti! Jāpieskaņo kartes stils, lai informācijas daudzums un prezentācija būtu pašam pa gaumei, tad tas jālieto un jāiesaka citiem ;-) ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Bet nu šeit nav informācijas pat to, no kurienes nāk dati. Tā kā tilti nav redzami dabā, tad ir jautājums par autortiesībām. Un manuprāt vajadzētu nošķirt RD uzģenerētos vēlamos risinājumus no patiešām reāliem projektiem. Diez vai tuvāko gadu laikā mēs ieraudzīsim tiltu skaita dubultošanos. 2012/6/25 cuu...@gmail.com cuu...@gmail.com Jādzēš ārā šie tilti! Jāpieskaņo kartes stils, lai informācijas daudzums un prezentācija būtu pašam pa gaumei, tad tas jālieto un jāiesaka citiem ;-) -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Zemgales tilts, Mazais tilts
Tad pieliec source pie sazīmētajiem proposed! 2012/6/25 Raitis U. rait...@gmail.com Kur izņemot OSM vēl ir puslīdz jēdzīgi parādīti plānotie tilti vienkopus? Avots ir terplāna grafiskā daļa, kurā ir noteiktās sarkanās līnijas. Man liekas mēs šito jau izrunājām... Oficiāls tags ir? Ir. (proposed vai planned) Routingā tiek izmantots? Nē. Jūs gribat rādīt tikai reālo situāciju - tb construction, bet man jau vairākiem cilvēkiem ir sanācis parādīt piemēram, kur tad īsti ies Piejūras šoseja un kādi izskatīsiesD-tilta apļi Daugavas rietumu krastā. Šeit jau tā ir salikti tikai lielie autoceļi, nevis kaut kādas mazās ieliņas... Ja nepatīk, ka renderī rādās - ir Hikebike, Mapsurfer, Kosmosnimki, un vēl vesela čupa renderēti tiles, kuros nerādās tas pasākums. 2012/6/25 cuu...@gmail.com cuu...@gmail.com Jādzēš ārā šie tilti! Jāpieskaņo kartes stils, lai informācijas daudzums un prezentācija būtu pašam pa gaumei, tad tas jālieto un jāiesaka citiem ;-) ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-cz] Data RUIAN - výměnný formát
Zdravím, katastr zachycuje *právní* stav, nikoliv realitu. Takže je určitě hodně budouv, které jsou na mapách a ve skutečnosti neexistují (zrovna o víkendu jsme jezdili po zaniklých vesnicích v Českém lese a některé budovy stále ještě v mapách KN jsou) nebo ve skutečnosti existují, ale v mapách KN nejsou (buď černé stavby, nebo stavby, které nejsou předmětem evidence v katastru). Uliční čáry jsou (budou). Jedná se o import ze ZABAGED. J. Veselý Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Data RUIAN - výměnný formát Datum: 25.6.2012 01:36:52 (nebo jsou data nesprávná - např. jiný tvar obrys budovy). *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat za standard. Řekněme, že zde mohou např. fakticky existující budovy chybět (postavené načerno apod.). V tak rozsáhlých informacích bych se divil, kdyby to bylo opravdu bez chyb. Na druhou stranu jako základ to určitě smysl má, protože je to (v daných oblastech) asi to nejlepší, co máme. Ale s ručními zásahy je třeba počítat. obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v ukazkach nic nenašel Asi opravdu uliční čáry, viz třeba: vf:Ulicevf:Ulice gml:id=UL.454281uli:Kod454281/uli:Koduli:NazevLešanská/uli:Nazevuli:Obecobi:Kod554782/obi:Kod/uli:Obeculi:PlatiOd2011-07-01T00:00:00/uli:PlatiOduli:IdTransakce0/uli:IdTransakceuli:GlobalniIdNavrhuZmeny0/uli:GlobalniIdNavrhuZmenyuli:Geometrieuli:DefinicniCaragml:MultiCurve gml:id=DUL.454281.X srsName=urn:ogc:def:crs:EPSG::2065 srsDimension=2gml:curveMembergml:LineString gml:id=DUL.454281gml:posList738883.65 1048327.51 738848.15 1048382.19 738819.05 1048435.52/gml:posList/gml:LineString/gml:curveMember/gml:MultiCurve/uli:DefinicniCara/uli:Geometrie/vf:Ulice Které konrétní údaje z registru se budou do OSM importovat? *AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) Já myslím, které vlastnosti těchto entit. Užitečné by bylo napojení na registry pomocí IDček apod. Jak se vypořádat se starými daty? *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro source=cuzk:km) a ponechat pripadne tagy navic. Což znamená namatchovat k nové budově tu starou, aby bylo možné zkopírovat tagy. Otázka je, jak. Budovy nemusí být zakresleny přesně a není jisté, že budou fungovat nějaké metody typy X má průsečík s Y apod. Dost digitalizaci je neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu) nebo pokryti zdanlive hotoveho uzemi. Také bude třeba kontrolovat, že node není sdílený s něčím jiným. Rovně může dojít k nějakým nechtěným průsečíkům, pokud budova byla nakreslena odlišně a obdobně jsou nakresleny i okolní objekty. S ulicemi, které mají návaznosti, bude také asi celkem problém. V registrech je jen něco (nebo to prostě není ulice, ale něco fakticky podobného). Obdobne u adresnich bodu, coz je dano nedokoncenym importem a zdrojem dat. Adresní body budou asi celkem v pohodě. Za ideální cílový stav bych považovat navázání dat na registr kvůli aktualizacím. *** To je zbozne prani, ktere se nam doposud nepovedlo, viz napr.: 1) adresni body obcas nekdo strka do POI ci polygonu building 2) admin_border se staly soucasti multipolygonu budov a ruznych preklepu... 3) import rek DIBAVOD, a lesu UHUL uz je prakticky neudrzovatelny s originalem Zatím ano, ale tady bych to neviděl jako nemožné. U entit bych nechával v tagu návaznost na registr ve formě ID. Pak bude možné automaticky detekovat, kde došlo k ruční úpravě a kde ne, stejně tak ze změnových souborů bude možné snadno zjišťovat změny v registrech a neupravované entity automaticky opravovat. U těch, kde byl proveden manuální zásah, tak tam bude třeba asi ruční posouzení, ale toho bude předpokládám málo. Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s daty v budoucnosti. Souhlas, proto považuji za nezbytné to nejprve prodiskutovat a vybrat nějaké nejlepší řešení a pak jej implementovat. Adresy, obrysy budov Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Dne 25.6.2012 0:35, hanoj napsal(a): (nebo jsou data nesprávná - např. jiný tvar obrys budovy). *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat za standard. Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji. A pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp) nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou (a to jsou zborene uz minimalne par let). = 1) zadny zbesily import a rozhodne ne zadne mazani v OSM. 2) optimalne vygenerovani nejake kolizni mapy (wms/tms server) aby sla dat na podkres editoru. 3) IMo by bodnul nastroj, kterej by byl schopnej nejak slinkovat existujici budovy - rekneme s nejakym rozpalem hranic +- 1m? a ohranicene plochy +- 10%? Cisla by samo chtelo vyhodnotit na zaklade uspesnosti = pokud zbude nejaky nepatrny % budov, ty se daj poresit rucne. Pokud se budova vejde to tohodle rozpalu (IMO vsechny vyrobeny tracerem), tak se da prohlasit, ze to je ona, priradit ji prislusny ID a posunout jeji hranice tak, aby to sedelo presne na km. Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v osm (a nejakym marknutim objektu ho vyradi ze synchronizace). obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v ukazkach nic nenašel Které konrétní údaje z registru se budou do OSM importovat? *AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) Jak se vypořádat se starými daty? *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro source=cuzk:km) a ponechat pripadne tagy navic. Dost digitalizaci je neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu) nebo pokryti zdanlive hotoveho uzemi. Obdobne u adresnich bodu, coz je dano nedokoncenym importem a zdrojem dat. Za ideální cílový stav bych považovat navázání dat na registr kvůli aktualizacím. *** To je zbozne prani, ktere se nam doposud nepovedlo, viz napr.: 1) adresni body obcas nekdo strka do POI ci polygonu building 2) admin_border se staly soucasti multipolygonu budov a ruznych preklepu... 3) import rek DIBAVOD, a lesu UHUL uz je prakticky neudrzovatelny s originalem Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s daty v budoucnosti. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import budov
Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1]. Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu. Jde o to, že v jednom katastrálním území je někdy více částí obcí. V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru. Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0d=1 On Thu 21-06-12 22:11:45, xkomc...@centrum.cz wrote: Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax __ Od: jzvc j...@tpfree.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 21.06.2012 19:40 Předmět: Re: [Talk-cz] Import budov On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr cervenou tecku, ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na starsi oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi. Dne 21.6.2012 19:23, xkomc...@centrum.cz napsal(a): Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka probíhá, ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import budov
Ahoj, s importem adresních bodů získaných z teček na mapě bych se teď moc nezatěžoval, protože v brzké době se doufám podaří provést import z RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to nejjednodušší, co z RUIAN půjde naimportovat. Honza Dne 25. června 2012 13:50 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1]. Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu. Jde o to, že v jednom katastrálním území je někdy více částí obcí. V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru. Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0d=1 On Thu 21-06-12 22:11:45, xkomc...@centrum.cz wrote: Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax __ Od: jzvc j...@tpfree.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 21.06.2012 19:40 Předmět: Re: [Talk-cz] Import budov On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr cervenou tecku, ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na starsi oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi. Dne 21.6.2012 19:23, xkomc...@centrum.cz napsal(a): Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka probíhá, ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import budov
Ahoj Honzo, Souhlas. Sám se už dlouho těším na zdroj dat jako je RUIAN se kterým půjdou přetáhnout již existující informace do OSM, místo jejich znovuobjevování. Na druhou stranu, ještě nemáme žádné nástroje, které by RUIAN používaly a tady je přispivatel, který chce mapu vylepšit. Sám za sebe mu raději řeknu co může udělat dnes, místo abych ho nabádal počkat až bude software používající nové postupy. Libor On Mon 25-06-12 13:56:56, Jan Bilak wrote: Ahoj, s importem adresních bodů získaných z teček na mapě bych se teď moc nezatěžoval, protože v brzké době se doufám podaří provést import z RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to nejjednodušší, co z RUIAN půjde naimportovat. Honza Dne 25. června 2012 13:50 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1]. Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu. Jde o to, že v jednom katastrálním území je někdy více částí obcí. V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru. Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0d=1 On Thu 21-06-12 22:11:45, xkomc...@centrum.cz wrote: Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax __ Od: jzvc j...@tpfree.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 21.06.2012 19:40 Předmět: Re: [Talk-cz] Import budov On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr cervenou tecku, ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na starsi oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi. Dne 21.6.2012 19:23, xkomc...@centrum.cz napsal(a): Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka probíhá, ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj, jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Honza Dne 25. června 2012 12:16 jzvc j...@tpfree.net napsal(a): Dne 25.6.2012 0:35, hanoj napsal(a): (nebo jsou data nesprávná - např. jiný tvar obrys budovy). *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat za standard. Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji. A pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp) nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou (a to jsou zborene uz minimalne par let). = 1) zadny zbesily import a rozhodne ne zadne mazani v OSM. 2) optimalne vygenerovani nejake kolizni mapy (wms/tms server) aby sla dat na podkres editoru. 3) IMo by bodnul nastroj, kterej by byl schopnej nejak slinkovat existujici budovy - rekneme s nejakym rozpalem hranic +- 1m? a ohranicene plochy +- 10%? Cisla by samo chtelo vyhodnotit na zaklade uspesnosti = pokud zbude nejaky nepatrny % budov, ty se daj poresit rucne. Pokud se budova vejde to tohodle rozpalu (IMO vsechny vyrobeny tracerem), tak se da prohlasit, ze to je ona, priradit ji prislusny ID a posunout jeji hranice tak, aby to sedelo presne na km. Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v osm (a nejakym marknutim objektu ho vyradi ze synchronizace). obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v ukazkach nic nenašel Které konrétní údaje z registru se budou do OSM importovat? *AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) Jak se vypořádat se starými daty? *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro source=cuzk:km) a ponechat pripadne tagy navic. Dost digitalizaci je neduslednych co do geometrie tvaru (krizeni,
Re: [OSM-talk-fr] Tracker sur téléphone portable Android
Le 24/06/2012 21:01, vope a écrit : Bonsoir, Bonjour ! (c'est déjà le matin !), Je possède un téléphone portable Android avec la fonction AGPS, mais je n'ai pas d'abonnement internet associé (3G). Est-il possible d'installer une application Android pour enregistrer mes traces GPS, sans avoir d'abonnement internet lié à mon forfait téléphonique, afin de les envoyer vers OSM ? Ce sujet est abordé périodiquement sur cette liste ; En conclusion, la dernière fois qu'on en a discuté, la satisfaction des gens dépend de 3 paramètres : 1) Il faut que le smartphone ait un bon gps, de l'espace de stockage (une sd c'est mieux) et surtout que la batterie ne s'épuise pas en dix minutes quand le gps est en service. 2)Il faut que le système d'exploitation gère correctement ce gps : en gros, avant la 2.2 froyo, c'est pas terrible ; un point critique est le temps mis pour faire le fix, c'est à dire le temps qu'il lui faut pour faire le point à la mise en service ; 3)In fine, OsmTracker a aussi sa part d'aléa : quand on se déplace il peut lui arriver de ne pas s'en apercevoir si l'ensemble gps+SE est trop boeuf ; LG donnait satisfaction, Samsung spica faisait peine. Mais maintenant il y a Samsung galaxy S3, et un copain qui l'a me dit que c'est super pour cartographier ; je verrais ça avec lui en juillet. Si oui quelle application puis-je installer ? osmTraker me semble pas mal, mais je n'ai pas encore le smartphone qui va bien. perso, j'utilise un increvable geko301 pour collecter mes traces, il n'a pas de carto embarqué, mais il est tout petit, étanche à la pluie, très sensible (il reste pertinent en sous-bois) et ne consomme presque rien en batterie. Je prends aussi des photos géoréférencées avec un sony DSC-HX5 ; lui par contre est énergivore, et je lui emmène toujours 2 batteries de rallonge quand je pars en randonnée. Merci par avance. À la prochaine ! Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Champs de lavande : Landuse=lavender ?
2012/6/23 kimaidou kimai...@gmail.com: Je me demandais quels tags utiliser ? Pour l'instant j'ai mis landuse=lavender , mais je corrige dès que vous me donnez une meilleure nomenclature. Il faut sûrement utiliser un landuse=farm avec une combinaison species=lavender ? landuse=farm + subkey est préfèrable (je mentionnerais bien landcover). Mais attention, il y a une certaine réticence à indiquer ce qui est cultivé lorsqu'il y a rotation des cultures, ce qui n'est pas le cas des vignobles ou des vergers par exemple qui ont leurs propres tags. Alors que c'est le cas, je crois, des champs de lavande (même si les cycles s'étalent sur plusieurs années). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Champs de lavande : Landuse=lavender ?
Bonjour, Merci pieren. J'avais aussi pensé à landuse=orchard trees=lavender Mais bien sûr le problème c'est que la lavande n'est pas un arbre ni arbuste. Par contre, c'est quand même assez pérenne comme plantation. Ça me gêne un peu de ne pas préciser du tout la culture. Un simple landuse=farm n'apporte rien je trouve. Va pour un landuse=farm species=lavender ? Bon début de semaine à tou(te)s Michael Le 25 juin 2012 10:22, Pieren pier...@gmail.com a écrit : 2012/6/23 kimaidou kimai...@gmail.com: Je me demandais quels tags utiliser ? Pour l'instant j'ai mis landuse=lavender , mais je corrige dès que vous me donnez une meilleure nomenclature. Il faut sûrement utiliser un landuse=farm avec une combinaison species=lavender ? landuse=farm + subkey est préfèrable (je mentionnerais bien landcover). Mais attention, il y a une certaine réticence à indiquer ce qui est cultivé lorsqu'il y a rotation des cultures, ce qui n'est pas le cas des vignobles ou des vergers par exemple qui ont leurs propres tags. Alors que c'est le cas, je crois, des champs de lavande (même si les cycles s'étalent sur plusieurs années). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouvrages militaires historiques, Maginot, Séré, Festung etc.
Le 23 mai 2012 13:02, Tetsuo Shima tets...@gmail.com a écrit : Dans le nord est de la France on a énormément d'ouvrage militaire, ouvrage visible un peu partout et dont les emprises structure une partie du paysage. Le souci c'est que je ne sais absolument pas comment les tagger proprement. - l'emprise de l'ouvrage ... on met la surface en landuse? en military? autre chose? idealement il faudrait un tag genre amenity comment on signifie que c'est un ancienne zone militaire? En général l'ancienne emprise laisse des marques geographiques importantes ne serait qu'a cause de l'usage de la parcelle, plus ou moins abandonné aux herbes folles ou a la foret. - les tourelles et autre casemate partiellement visible en surface. La plupart du temps il est pas possible de dessiner le bâti, celui ci étant presque exclusivement caché sous terre. Le plus simple serait de tagger juste un node par casemates/tourelle/bloc. Mais on les tag comment? juste military=bunker? c'est pas très explicite. historic=castle ne semble pas tres juste non plus? On est tres loin du château même pour un fort Seré. Je réponds qu'en partie. J'ai choisi historic=fort. Pour le reste je ne suis pas encore rentré dans tous ces détails... Romain - les fossés et autres champs de barbelés, obstacle antichar dangereux a franchir pour un randonneur ... tagger fence est pas très pertinent non plus? J'ai fouillé dans le wiki sans trouver grand chose donc je vous appele au secours ^_^ Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [accessibilité] Mobile en ville libéreront-ils leurs données ? ^^
Pour info, j'ai rencontré hier le président Alain Lehaire sur le stand Mobile en Ville pendant les Solidays. On a eu une longue discussion : très ouvert à une collaboration OSM, à changer la licence de leurs docs, voir à organiser une mapping party commune :) Ils manquent d'outils et de compétences informatiques : pour l'instant leurs cartes sont encore papier. Si libération de données il y a, un gros boulot d'intégration est à prévoir. Nous prévoyons de nous revoir rapidement. Que du bon, à suivre ... ++ Le 22 juin 2012 10:17, Florian LAINEZ winner...@free.fr a écrit : Tu es tout à fait dans le sujet, et je t'encourage à monter une mapping party accessibilité. Le mieux est de mixer contributeurs OSM et personnes touchées de handicap. ça s'est déjà fait dans pas mal de villes : http://wiki.april.org/w/Cartopartie_Accessibilit%C3%A9, à Toul de s'y mettre ! Si tu as besoin d'aide, je suis à ta dispo. ++ Le 22 juin 2012 09:56, Romain MEHUT romain.me...@gmail.com a écrit : Le 22 juin 2012 09:43, Florian LAINEZ winner...@free.fr a écrit : hey, pour l'instant il n'y a que cette carte : http://mobileenville.free.fr/plans/toul/toul.html qui est un scan d'un document réalisé à la main. C'est très laid et pratiquement inutilisable; j'aimerai qu'ils mettent toutes ces infos dans OSM. Le mieux serait de leur faire une cartopartie et des les former à nos outils ... Pour la ville de Toul, il doit y avoir des personnes handicapés qui veulent cartographier autour de toi. Tu veux que je te mette en contact directement ? Oui si c'est bien le cas. Autant Toul est maintenant bien cartographiée dans OSM, autant je ne me suis pas encore intéressé à l’accessibilité mais je pourrais former ces personnes à la contribution et trouver des relais dans Toul pour organiser des cartoparties ciblées... Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Champs de lavande : Landuse=lavender ?
Salut Michael le wiki [1] précise que la valeur de l'espèce doit être donnée en Latin, soit Lavandula angustifolia (si c'est de la lavande vraie, si c'est du Lavandin, tu corrigeras [2]) Si tu ne connais pas l'espèce, tu met juste le genre (tag genus) Tu peux aussi ajouter le tag species avec l'espace de nom fr : species:fr=Lavande vraie ça donnerait un truc dans le genre : landuse=farm genus=Lavandula species=Lavandula angustifolia species:fr=Lavande vraie Cordialement, Mika_Gueret [1] http://wiki.openstreetmap.org/wiki/Key:species [2] http://fr.wikipedia.org/wiki/Lavande Le lundi 25 juin 2012 à 10:32 +0200, kimaidou a écrit : Bonjour, Merci pieren. J'avais aussi pensé à landuse=orchard trees=lavender Mais bien sûr le problème c'est que la lavande n'est pas un arbre ni arbuste. Par contre, c'est quand même assez pérenne comme plantation. Ça me gêne un peu de ne pas préciser du tout la culture. Un simple landuse=farm n'apporte rien je trouve. Va pour un landuse=farm species=lavender ? Bon début de semaine à tou(te)s Michael Le 25 juin 2012 10:22, Pieren pier...@gmail.com a écrit : 2012/6/23 kimaidou kimai...@gmail.com: Je me demandais quels tags utiliser ? Pour l'instant j'ai mis landuse=lavender , mais je corrige dès que vous me donnez une meilleure nomenclature. Il faut sûrement utiliser un landuse=farm avec une combinaison species=lavender ? landuse=farm + subkey est préfèrable (je mentionnerais bien landcover). Mais attention, il y a une certaine réticence à indiquer ce qui est cultivé lorsqu'il y a rotation des cultures, ce qui n'est pas le cas des vignobles ou des vergers par exemple qui ont leurs propres tags. Alors que c'est le cas, je crois, des champs de lavande (même si les cycles s'étalent sur plusieurs années). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Champs de lavande : Landuse=lavender ?
Salut Mickael, En effet, il faut préciser l'espèce en latin. Par contre, je ne pourrais pas être précis (entre lavande vrai, autres lavandes ou lavandin). Normalement, l'altitude est déjà un bon moyen de savoir si c'est de la lavande vraie, mais bon... Je laisse aux contributeurs locaux le loirsir de préciser. Va donc pour landuse=farm genus=Lavandula genus:fr=Lavande Merci, Michaël Le 25 juin 2012 11:12, Mickaël Guéret m.gue...@free.fr a écrit : Salut Michael le wiki [1] précise que la valeur de l'espèce doit être donnée en Latin, soit Lavandula angustifolia (si c'est de la lavande vraie, si c'est du Lavandin, tu corrigeras [2]) Si tu ne connais pas l'espèce, tu met juste le genre (tag genus) Tu peux aussi ajouter le tag species avec l'espace de nom fr : species:fr=Lavande vraie ça donnerait un truc dans le genre : landuse=farm genus=Lavandula species=Lavandula angustifolia species:fr=Lavande vraie Cordialement, Mika_Gueret [1] http://wiki.openstreetmap.org/wiki/Key:species [2] http://fr.wikipedia.org/wiki/Lavande Le lundi 25 juin 2012 à 10:32 +0200, kimaidou a écrit : Bonjour, Merci pieren. J'avais aussi pensé à landuse=orchard trees=lavender Mais bien sûr le problème c'est que la lavande n'est pas un arbre ni arbuste. Par contre, c'est quand même assez pérenne comme plantation. Ça me gêne un peu de ne pas préciser du tout la culture. Un simple landuse=farm n'apporte rien je trouve. Va pour un landuse=farm species=lavender ? Bon début de semaine à tou(te)s Michael Le 25 juin 2012 10:22, Pieren pier...@gmail.com a écrit : 2012/6/23 kimaidou kimai...@gmail.com: Je me demandais quels tags utiliser ? Pour l'instant j'ai mis landuse=lavender , mais je corrige dès que vous me donnez une meilleure nomenclature. Il faut sûrement utiliser un landuse=farm avec une combinaison species=lavender ? landuse=farm + subkey est préfèrable (je mentionnerais bien landcover). Mais attention, il y a une certaine réticence à indiquer ce qui est cultivé lorsqu'il y a rotation des cultures, ce qui n'est pas le cas des vignobles ou des vergers par exemple qui ont leurs propres tags. Alors que c'est le cas, je crois, des champs de lavande (même si les cycles s'étalent sur plusieurs années). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] OSM : Information sur erreur chevauchement batiment/way
Le 24 juin 2012 10:54, Rodolphe Quiedeville rodol...@quiedeville.org a écrit : joedalton85 a écrit on 23/06/12 13:54: Osmose ne sait pas détecter l'antériorité des ways les uns par rapport aux autres ? Non rien de ce genre dans Osmose. L'erreur porte sur deux objets, donc deux fautifs. La liste des erreurs par utilisateur n'est que du signalement. Comme Osmose ne gère pas l'historique, l'erreur est signalé au dernier ayant modifié l'objet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr]hello world
Le message suivant de : ## Bonjour à tous, Je suis webmaster dans une école d'art, et depuis cette année je m'interresse de près a google map api, mais je suis bien conscient qu'il serait plus judicieux d'utiliser l'API d'open street map. Aussi j'ai une question peut être stupide, existe t'il un equivalent à la fonction ImageMapType qu'offre google map api. A savoir une fonction qui permet le remplacement des tuiles par celles qu'on souhaites . Elle est notement utilisé pour creer le google moon, mais peut être etendu a un peu n'importe quel projet. Mon but n'etant pas de creer des cartes réelle mais uniquement d'expoiter le système de navigation qu'offre de telle carte (zoom grag and drop ...) voir un exemple ici : http://www.ensba-lyon.fr/horsmurs/1112/JulienCreuzet/sandretto_map/testmap.html merci a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=10 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]hello world
Avec Openlayers, je pense qu'il n'y a aucun problème a afficher son propre tuilage. Maintenant, il faut qu'il y ait un service qui alimente le tuilage (serveur carto). -- View this message in context: http://gis.19327.n5.nabble.com/forum-osm-fr-hello-world-tp5714091p5714094.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]hello world
Bonjour, il faut qu'il y ait un service qui alimente le tuilage (serveur carto). Oui mais non ;) pour ton besoin. Il faut comme le dit partir en vtt pouvoir générer des tuiles (il a raison sur ce point) mais à partir du moment où ce n'est pas de la carte géoréférencée, le serveur carto n'est pas très utile. En effet, depuis quelques années déjà, il y a une fonction qui supporte Zoomify (qui permet de tuiler de l'image classique) dans OpenLayers (la bibliothèque qu'utilise OpenStreetMap) La liste des outils côté serveur pour générer ces rendus (de manière facile) est dans la page OpenLayers associée http://openlayers.org/dev/examples/zoomify.html Cordialement ThomasG ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Maps API : Google simplifie son offre et réduit ses tarifs de 87 %
Est ce que cela va suffir a faire revenir certains gros sites dans le giron de Google Maps ? http://www.pcinpact.com/news/71893-google-maps-api-regles-assouplissement.htm Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] MissingCommunes en pause cause OSM7 plus à jour
Salut, Juste pour prévenir que j'ai mis en mode maintenance le petit service MissingCommunes car les données n'étaient plus à jour suite au problème rencontré sur le serveur OSM8.openstreetmap.fr qui semble alimenter les données d'OSM7 qui sert de base à MissingCommunes. A suivre donc. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Indoor mapping et Tour Montparnasse
salut, Le 20 juin 2012 18:19, Nicolas Moyroud nmoyr...@free.fr a écrit : Mais par contre OSM-3D va adorer ! http://wiki.openstreetmap.org/wiki/OSM-3D J'avais entendu parler de ça mais je n'étais jamais allé voir. Je n'ai pas l'impression que l'outil prenne en compte le tag *level, *à chaque fois il faut préciser la hauteur en mètres, à moins que la synchro avec la base OSM soit un peu longue ... bref ça me donne des idées pour 3Disé (oui oui ça se dit ^^) le quartier ... Le 20 juin 2012 21:51, JonathanMM jonatha...@nocle.fr a écrit : Pourquoi te taperait-on ? Y'en a bien qui font du micromapping avec la hauteur des trottoirs en mm ^^' oui, moi ! ^^ #accessibilité Le 20 juin 2012 21:51, JonathanMM jonatha...@nocle.fr a écrit : Sur la page http://wiki.openstreetmap.org/wiki/Indoor_Mapping il y a une liste d'exemples, mais aucune tour haute. Du coup ils utilisent les layers, limités à 11 niveaux (de -5 à +5), ce qui ne m'arrange pas trop. Tu as le tag level=* pour ça ;) Autant les layers servent à définir qui doit être affiché au dessus de qui, autant le tag level doit aussi le faire (voir empêcher le rendu pour certains rendus, mais c'est au rôle des rendus de se débrouiller ^^') c'est parti pour une utilisation intensive du tag level ! Du coup j'ai précisé ça aussi pour la tour eiffel :) Je vois que personne n'est vraiment fixé sur le sujet, je ne vais donc pas *trop *m'investir la-dedans. Ceci-dit, j'ai commencé à mettre des nodes un peu partout dans la tour, et également dans le centre commercial juste à proximité. Pour l'instant cela me semble le plus judicieux. ++ Le 22 juin 2012 07:58, Philippe Verdy verd...@wanadoo.fr a écrit : Il me semble que tout ça est trop expérimental et qu il vaudra mieux une base à part pour stocker des modèles 3d dans un schéma plus conventionnel. Osm n à pas de vrai support 3d c est du bricolage que vous faites et qui rend keske cartes inutilement compliquées. On en reparlera lorsque la base sera scindée en sous bases pour gérer séparément dans des casques distincts la géographie physique, la géographie humaine politique et administrative et Surtout le bâti qui occupe une place déjà trop importante par rapport à tout le reste et qu on finira vite par séparer du reste avant même de songer à le modéliser en 3d Le 22 juin 2012 01:51, Tetsuo Shima tets...@gmail.com a écrit : Bonjour, Si on regarde le modèle OSM-3D effectivement un polygone suffit pour décrire les limites extérieures d'un building de plusieurs étages, donc les niveaux sont superposables. On part du principe que par défaut tous les niveaux ont même forme, autrement c'est signalé par les tag min_level=* et levels=* associés au polygone qui est étiqueté build=*. En cas d'empilement de building de plusieurs forme genre les derniers étages de l'Empire State, il faut ajouter un polygone de chaque sorte avec les min_level=* et levels=* qui vont bien pour signifier l'intervalle de validité - de l'extrusion en quelques sortes -. Jusque là c'est assez simple pour l'enveloppe externe. Pour l'interieure par contre il faut que chaque élément dispose d'un tag level=* pour le situer ... pour les éléments à plusieurs étages comme un restaurant en duplex ... mystère. level=2;3 ?? Pour un tag entrance=main ajouté sur le pourtour d'une surface, est-il nécessaire d'ajouter le level=* ou c'est hérité de la surface? ou il faut ajouter systématiquement? seulement dans les cas indéfinis - comme les surfaces multi-niveaux - ? Cordialement. 2012/6/21 Vincent Pottier vpott...@gmail.com: Le 21/06/2012 13:48, te...@free.fr a écrit : Salut, Question importante, est-ce que dans ce type de mapping, avec des zones qui se recouvrent à la verticale, il est recommandé de : - réutiliser les mêmes nodes (dans le sens node=ligne verticale virtuelle à certaines coordonnées), - ou de superposer des nodes différents (node=point de repère symbolique qui peut également être localisé en altitude) ? Teuxe Ce qui DEVRA être distinct, c'est l'objet portant le tag level : le nœud pour les POIs ponctuels, le polygone pour des surfaces. Si les limites sont structurellement alignées verticalement, il me semble logique que les nœuds soient partagés, sans avoir d'autre caractéristique que leur position. Ce qui, pour la Tour Montparnasse (6 niveaux en sous-sol + 58 étages) risque de faire 64 polygones superposés... Bonjour l'édition ! -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian
[OSM-talk-fr] [forum-osm-fr]Du nord au sud
Le message suivant de : ## Bonjour à tous, Adepte du libre et de Gnu/Linux,depuis une dizaine d'années, j'ai rencontré openstreetmap dans l'essonne avec [url]http://liness.org[/url], je viens de déménager dans le sud à Malaucène 84340, où j'ai très envie de mettre à jour la carte du pays. Voila, j'ai commencé depuis quelques jours. Merci à Mercator et à ab_fab pour leur aide. Je commence par ce qui est autour de chez moi, et j'espère aller de plus en plus loin. Le virus s'est attaqué à moi, et je n'ai pas pu résister :-) La retraite ça permet de se faire plaisir. je reviendrai pour avoir de l'aide, parceque il y à pas mal de chose que je comprends pas trop. cordialement et librement jipenunux a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=10 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] ODbLオンライン勉強会(その8)
3.0 RIGHTS GRANTED 3.0 許諾対象の権利 3.1 Subject to the terms and conditions of this License, the Licensor grants to You a worldwide, royalty-free, non-exclusive, terminable (but only under Section 9) license to Use the Database for the duration of any applicable copyright and Database Rights. These rights explicitly include commercial use, and do not exclude any field of endeavour. To the extent possible in the relevant jurisdiction, these rights may be exercised in all media and formats whether now known or created in the future. The rights granted cover, for example: a. Extraction and Re-utilisation of the whole or a Substantial part of the Contents; b. Creation of Derivative Databases; c. Creation of Collective Databases; d. Creation of temporary or permanent reproductions by any means and in any form, in whole or in part, including of any Derivative Databases or as a part of Collective Databases; and e. Distribution, communication, display, lending, making available, or performance to the public by any means and in any form, in whole or in part, including of any Derivative Database or as a part of Collective Databases. 3.1 本ライセンスの条件に従って、許諾者は、あなたに対して、該当する著作権及びデータベース権の有効期間中、本データベースの利用を目的とした全世界的、非独占的、解除可能（ただし、第9条に従わなければならない。）、かつ、ロイヤルティ支払義務が存在しないライセンスを許諾する。以上の権利は、商業利用を明示的に対象に含むとともに、いかなる分野も対象から排除しない。該当する法域において可能である限りにおいて、以上の権利は、現時点で知られているか、将来において開発されるかを問わず、あらゆる媒体及びフォーマットにおいて行使することができる。 許諾対象の権利は、例えば、以下を対象とする。 a. コンテンツの全体又は実質的部分の抽出及び再利用。 b. 派生データベースを作成すること。 c. 集合データベースを作成すること。 d. あらゆる方法及び形式によって、一時的又は恒久的な複製を、全体か一部かを問わず作成すること。派生データベースとして、又は集合データベースの一部として作成することを含む。 e. あらゆる方法及び形式によって、全体か一部かを問わず、公衆に向けて頒布、伝達、表示、貸与、公開、又は実演すること。派生データベースとして、又は集合データベースの一部についてこれらを行うことを含む。 //メモ（ここから↓）- このライセンスでどんなことができるかということが書かれています。 著作権の保護期間は日本では著作権者の死亡後50年（映画のみ70年）です。EUのデータベース権は15年（追加・修正による延長あり）です。 --メモ（ここまで↑）---// 3.2 Compulsory license schemes. For the avoidance of doubt: a. Non-waivable compulsory license schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; b. Waivable compulsory license schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and, c. Voluntary license schemes. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License. 3.2 ライセンス制度の強制適用: 疑義を避けるために、以下を定める。 a. 放棄できない強制ライセンス制度: 制定法上のライセンス制度、又は強制的なライセンス制度に基づいてロイヤルティの支払を受ける権利がある場合に、これを放棄することができない法域においては、許諾者は、あなたが本ライセンスに基づく権利を行使したことを理由として、ロイヤルティの支払を受ける独占的権利を保有する。 b. 放棄可能な強制ライセンス制度: 制定法上のライセンス制度、又は強制的なライセンス制度に基づいてロイヤルティの支払を受ける権利がある場合に、これを放棄することができる法域においては、許諾者は、あなたが本ライセンスに基づく権利を行使したことを理由として、ロイヤルティの支払を受ける独占的権利を放棄する。 c. 任意的ライセンス制度: 許諾者は、あなたが本ライセンスに基づく権利を行使したことを理由として個人的にロイヤルティの支払を受ける権利を放棄し、又は、許諾者が任意的ライセンス制度を管理する著作権管理団体の会員である場合は、その団体からロイヤルティの支払を受ける権利を放棄する。 //メモ（ここから↓）- ODbLは基本的にロイヤルティ（対価）を要求しないが、国によってはその権利を放棄できないところがあるので、その場合は各国の法令を尊重し、譲るところは譲る、という話です。 --メモ（ここまで↑）---// 3.3 The right to release the Database under different terms, or to stop distributing or making available the Database, is reserved. Note that this Database may be multiple-licensed, and so You may have the choice of using alternative licenses for this Database. Subject to Section 10.4, all other rights not expressly granted by Licensor are reserved. 3.3 異なる条件下で本データベースを開放する権利、又は本データベースの配布若しくは公開を停止する権利は、これを留保する。本データベースについては、ライセンスを複数許諾することが可能であるため、あなたは、本データベースについて代替的なライセンスの使用を選択できる場合がある。第10.4項を条件として、許諾者が明示的に許諾していない他のあらゆる権利は、これを留保する。 //メモ（ここから↓）- この部分は正直よく分かっていません。何らかの条件に基づきデュアルライセンスを認める場合があるということなのでしょうか？ --メモ（ここまで↑）---// ODbL本文の対訳（非公式ドラフト） http://wiki.openstreetmap.org/wiki/OSMFJ/ODbL/1.0/text ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 地図と現地の表記が違う
という例を見つけてしまいました。 たぶん現地の表記が何らかの間違いか、理由があって省略 しているのだと思いますが。 もちろん現地の表記で投稿しておきます。地図のコピーはできませんし。 oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
