Re: [Talk-de] Suche nach OSM Spiel
Hallo Marc, ne Kort war das nicht. Wie gesagt so eine Art Puzzel mit Länderflächen. War wohl mit Java Script umgesetzt. Gruß Johannes Am 21.12.2014 um 07:49 schrieb Marc Gemis: Kort ? http://www.kort.ch/ gruß m 2014-12-21 0:49 GMT+01:00 Johannes jotpe@gmail.com: Hallo, ich suche ein Spiel, dass mal auf blog.openstreetmap.de vorgestellt wurde, wo man Länderumrisse auf die richtigen Stellen auf die Kontinente schieben musste. Mit der bescheidene Suchfunktion auf der Seite liefert Spiel ziemlich jede Woche als Treffer. Danke Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach OSM Spiel
Hallo Johannes, Am 2014-12-21 um 00:49 schrieb Johannes: ich suche ein Spiel, dass mal auf blog.openstreetmap.de vorgestellt wurde, wo man Länderumrisse auf die richtigen Stellen auf die Kontinente schieben musste. Mit der bescheidene Suchfunktion auf der Seite liefert Spiel ziemlich jede Woche als Treffer. https://www.google.de/search?q=spiel+site:blog.openstreetmap.de Das liefert eine ganze Ladung an Ergebnissen. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 663 Bäume mit identischer Internetaddresse..
Hi, sieht fast nach einem spam-Versuch aus? http://taginfo.openstreetmap.org/tags/?key=contact%3Awebsitevalue=http%3A%2F%2Fwww.ruheforst-vogelsberg.de%2Findex.php%3Fseite%3DKonzept%26h%3D2#overview Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 230 9.12.–15.12.2014
Hallo, die Wochennotiz Nr. 230 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-230/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aufsatz: Die Änderung des Lizenzmodells von OpenStreetMap
Hallo, in Mario Martini/Georg Thiel/Astrid Röttgen (Hrsg.), Geodaten und Open Government - Perspektiven digitaler Staatlichkeit, Speyer, November 2014 [Speyerer Forschungsberichte, Nr. 280] ist ein Aufsatz von mir zum Thema Die Änderung des Lizenzmodells von OpenStreetMap veröffentlicht worden. Die Publikation ist über http://www.foev-speyer.de/publikationen/pubdb.asp?reihen_id=1 als PDF zugänglich. Für den Download ist allerdings die Angabe eines Namens und einer E-Mailadresse notwendig. Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 230 9.12.–15.12.2014
Hallo, zweiter Versuch die Wochennotiz Nr. 230 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/12/wochennotiz-nr-230/ Viel Spaß beim Lesen! wn reader mailto:wnrea...@gmail.com 21. Dezember 2014 12:49 Hallo, die Wochennotiz Nr. 230 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-230/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Suche nach OSM Spiel
Du meinst wahrscheinlich https://gmaps-samples.googlecode.com/svn/trunk/poly/puzzledrag.html bzw http://bramus.github.io/mercator-puzzle-redux/ http://iknowtheworld.com/ bringt auch viel Spaß ;) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
Nein, kein spam. Der user hat 663 einzelne Baeume mit verschieden Koordinaten eingetragen. Das tagging ist zumindest ungewoehnlich und widerspricht der gaengigen Praxis, das als natural=tree nur alleinstehende oder aussergewoehnliche Baeume eingetragen werden (siehe http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree - Description: A single tree, often significant. ) Wir haben hier in der Naehe den Fall, dass ein user ueber 2 Baeume einzeln eingetragen hat (Massen-Import). Korrektes Tagging waere landuse=forest (in beiden Faellen) Warum schreibst du den user nicht an und machst ihn darauf aufmerksam. Ich glaube nicht, das es sich um einen boesartigen Versuch handelt. Volker (Padova, Italien) On 21 December 2014 at 12:41, Richard Z. ricoz@gmail.com wrote: Hi, sieht fast nach einem spam-Versuch aus? http://taginfo.openstreetmap.org/tags/?key=contact%3Awebsitevalue=http%3A%2F%2Fwww.ruheforst-vogelsberg.de%2Findex.php%3Fseite%3DKonzept%26h%3D2#overview Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aufsatz: Die Änderung des Lizenzmodells von OpenStreetMap
On Sunday 21 December 2014, Falk Zscheile wrote: [...] Die Publikation ist über http://www.foev-speyer.de/publikationen/pubdb.asp?reihen_id=1 als PDF zugänglich. Für den Download ist allerdings die Angabe eines Namens und einer E-Mailadresse notwendig. s/notwendig/erwünscht/ sieht so aus, dass der Download auch funktioniert, wenn man das Formular leer lässt. Eine inhaltliche Anmerkung: Du schreibst, dass die OSMF nach den CTs 'Inhaberin' der Daten ist - ich denke das ist etwas irreführend, denn de facto erhält sie vom Mapper nur eine uneingeschränkte aber explizit nicht exklusive Lizenz. Noch was anderes - Du stellst das Fehlen einer klaren konzeptionellen Trennung zwischen Daten und Darstellung ja als eine der zentralen Ursachen für die ursprüngliche Lizenzwahl heraus und begründest das in erster Linie historisch. Ich denke, dass das Fehlen einer solchen Trennung nach wie vor gerade auch in der professionellen Kartografie enorm verbreitet ist und OSM hier mittlerweile zumindest von den Ansätzen in vieler Hinsicht fast schon vorbildlich ist - wenngleich die praktische Umsetzung (Mapping für den Renderer) natürlich oft unzureichend ist. In jedem Fall insgesamt ein sehr schöner Text. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Samstag, 20. Dezember 2014 02:44 schrieb 715371 osmu715...@gmx.de: Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, Benutzungspflicht vorrausgesetzt. Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt). Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche indierekt über bicycle=use_sidepath oder durch die Unterscheidung von bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein anderes Thema. Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde. Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das doppelte Erfassen. Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen wie man sieht. Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt. Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde, dann würde ich den anschließenden Radweg nicht separat erfassen, weil es dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen. Dann stellt sich aber die Frage aber wann ein cycleway=track oder sidewalk=* nicht mehr an die Straßé getagged wird. Bordstein? Rasenfläche? Graben? Geländer? Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly lowfligh...@googlemail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem Schema so ergibt, dann ist es (auf einmal) Ok. Ich halte beides für nicht so gelungen. cycleway=* ist für mich ein Key mit dem man die Fahrradinfrastruktur an der Straße erfasst und würde es so verstehen, dass es zwei Radwege dort gibt, wenn es an der Straße einen cycleway=* gibt und daneben noch einen highway=path/cycleway/(footway). Daher sollte man IMHO für so etwas etwas anderes verwenden. Was in dem Kontext halt auch ungünstig ist: Die Bedeutung von footway=* ist nicht analog zu cycleway=*. cycleway eine weitere Bedeutung zu geben, macht es nicht einfacher. Ja, dass stimmt. Aber vieleicht kann man das auch wieder vereinheitlichen. Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer dieterdre...@gmail.com: da finde ich cycleway/sidewalk=separate_way oder ähnliches besser. jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass man erstens auch nicht genau weiss, welcher way, und zweitens bezieht man sich mit einem tag auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg verändert muss halt auch noch die Straße anschauen (und auch wenn das im Prinzip schon genau das Problem ist, so kann man es für Straßen vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe liegende, nicht genau spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben auf einem Node. Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter müsste erst nachsehen ob die (street-) Relation zu der die Straße gehört und dann ob in der Relation auch noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert bis unmöglich. Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane oder sidewalk=right an dieser Stelle nun gerendert wird. Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hab doch glatt die Links vergessen, die ich noch einfügen wollte: Seit 2011: wiki.osm.org/wiki/DE_talk:Bicycle/Radverkehrsanlagen_kartieren - Behauptungen, die diese Seite aufstellt -Punkt 4 http://wiki.openstreetmap.org/wiki/Talk:Sidewalks - Separated from the road by some form of barrier? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
Am 21.12.2014 um 13:57 schrieb Volker Schmidt: und widerspricht der gaengigen Praxis, das als natural=tree nur alleinstehende oder aussergewoehnliche Baeume eingetragen werden (siehe http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree - Description: A single tree, often significant. ) Dazu als Widerspruch (wobei ich diese Verwendung nicht als gut empfand!): Die Stadt http://wiki.osm.org/wiki/Girona hat im Vorfeld der dort stattfindenenden http://wiki.osm.org/wiki/State_Of_The_Map_2010 ihr Baumkataster für OSM zur Verfügung gestellt, welches importiert wurde = im Wald neben dem Veranstaltungszentrum (links auf der Karte) sind alle Bäum als Einzelbäume vorhanden... http://www.openstreetmap.org/#map=17/41.98684/2.81511 Grüße, Michael. PS: es gab während der SOTM 2010 Navi-/OSM-Software welche wegen der hohen Anzahl von Objekten dort gecrasht ist... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
die website gehört zu einem Friedhof. Das ganze IST EIN FRIEDHOF. ## Im Mittelpunkt eines RuheBiotopes steht immer ein Baum. Um diese Bäume herum können biologisch abbaubare Urnen beigesetzt werden ## Bäume sind da also eher wie Gräber zu sehen und die Namen unterscheiden sich auch, eben wie Grabnummern (sollte eher ref=* sein) Also man kann jetzt diskutieren ob das Sinn macht oder nicht, aber da hat sich schon jemand was bei gedacht. Ich würde jetzt eher eine relation für sinnvoll halten und auch die URL kürzer machen. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach OSM Spiel
War *wenig* hilfreich mit und zwischendurch ein Spiel…? beschrieben. http://blog.openstreetmap.de/blog/2014/04/wochennotiz-nr-193/ http://techslides.com/demos/d3/dragdrop-geo-game.html Drag and Drop Geography Game mit D3.js Gruß Johannes Am 21.12.2014 um 09:53 schrieb Michael Reichert: Hallo Johannes, Am 2014-12-21 um 00:49 schrieb Johannes: ich suche ein Spiel, dass mal auf blog.openstreetmap.de vorgestellt wurde, wo man Länderumrisse auf die richtigen Stellen auf die Kontinente schieben musste. Mit der bescheidene Suchfunktion auf der Seite liefert Spiel ziemlich jede Woche als Treffer. https://www.google.de/search?q=spiel+site:blog.openstreetmap.de Das liefert eine ganze Ladung an Ergebnissen. Viele Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
mit der Relation: RuheForst (1) Vogelsberg/Laubach (3304804) macht das dann alles Sinn, vorrausgesetzt die Originaldaten hatten die passende Lizenz. Ich habe kein source tag gesehen. Ausserdem haben di Baeume ein denotation=cluster, was ich nicht verstehe, und fuer das ich keine vernuenftige wiki Seite finde. 2014-12-21 16:06 GMT+01:00 Andreas Goss andi...@t-online.de: die website gehört zu einem Friedhof. Das ganze IST EIN FRIEDHOF. ## Im Mittelpunkt eines RuheBiotopes steht immer ein Baum. Um diese Bäume herum können biologisch abbaubare Urnen beigesetzt werden ## Bäume sind da also eher wie Gräber zu sehen und die Namen unterscheiden sich auch, eben wie Grabnummern (sollte eher ref=* sein) Also man kann jetzt diskutieren ob das Sinn macht oder nicht, aber da hat sich schon jemand was bei gedacht. Ich würde jetzt eher eine relation für sinnvoll halten und auch die URL kürzer machen. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
Das Thema Bäume mit „Nummer“ ist nicht nur auf diesen Bereich beschränkt. Ich wohne in einem Bereich mit registrierten Bäumen. Hier hat jeder Baum ein Wapperl mit eigener Nummer. Im Baumregister finden sich dann die „Daten“ zum Baum. Hier kannst du dich also an einem Baum treffen, einen Goldschatz vergraben oder… Gruß ludwich Am 21.12.2014 um 17:01 schrieb Volker Schmidt vosc...@gmail.com: mit der Relation: RuheForst (1) Vogelsberg/Laubach (3304804) macht das dann alles Sinn, vorrausgesetzt die Originaldaten hatten die passende Lizenz. Ich habe kein source tag gesehen. Ausserdem haben di Baeume ein denotation=cluster, was ich nicht verstehe, und fuer das ich keine vernuenftige wiki Seite finde. 2014-12-21 16:06 GMT+01:00 Andreas Goss andi...@t-online.de: die website gehört zu einem Friedhof. Das ganze IST EIN FRIEDHOF. ## Im Mittelpunkt eines RuheBiotopes steht immer ein Baum. Um diese Bäume herum können biologisch abbaubare Urnen beigesetzt werden ## Bäume sind da also eher wie Gräber zu sehen und die Namen unterscheiden sich auch, eben wie Grabnummern (sollte eher ref=* sein) Also man kann jetzt diskutieren ob das Sinn macht oder nicht, aber da hat sich schon jemand was bei gedacht. Ich würde jetzt eher eine relation für sinnvoll halten und auch die URL kürzer machen. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Negozio di bomboniere
On 2014-12-17 at 18:57:35 +0100, Martin Koppenhoefer wrote: applicare dei tags (ben usati) che non descrivono ciò che si cerca di descrivere viene comunemente chiamato tagging for the renderer. E' vero che spesso il tagging richiede dal mappatore una valutazione (se il tag ancora va bene o non più), e in questo caso delle bomboniere trovo che si tratta di una tipologia molto diversa da quella descritta per shop=gift: Selling gifts, and/or greeting cards. This also covers tourist gifts, otherwise known as souvenir shops. In sostanza chi cerca un negozio di bomboniere non cerca un souvenir shop e vice versa. E poi ci sono 3 foto, per esempio: http://wiki.osm.org/wiki/File:Gift_shop_interior.jpg http://wiki.osm.org/wiki/Tag:shop%3Dgift ma proprio quella pagina specifica che shop=gift non è in generale un negozio di souvenir: A London tourist souvenir shop. Note: This is not really a quintessential example of a 'gift shop'. Dalla descrizione mi pare che sia più una cosa per cui gift shop è in generale il negozio che vende cose inutili, che poi si suddivide in categorie come cose inutili da dare ai festeggiati, cose inutili da dare agli invitati, cose inutili da usare per far sapere che si è viaggiato. -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
Retromarcia sulla rimozione dei CAP: grazie a Fabrizio Tambussa, è stata fatta notare questa pagina web ( http://www.lineaamica.gov.it/opendata) del governo in cui ci sono tutti gli indirizzi della PA, comprendenti i CAP che mi servono per la Sardegna. I dati sono rilasciati in IODL 2.0, quindi perfettamente compatibili con la Odbl. Ho già aggiornato la pagina wiki dell'import in merito. Se non ci sono ulteriori critiche/mancanze nei prossimi giorni invierà la mail alla ML Import internazionale. Ciao e buone feste a tutti! Leonardo Il 18/12/2014 23:25, Leonardo Frassetto ha scritto: Ciao, ho aggiunto le informazioni mancanti e dopo una chiaccherata in IRC con il DWG, confermo che Wikipedia non può essere usata come fonte. A questo punto, non essendo critico come dato attualmente possiamo non metterlo in attesa di futuri rilasci di dati compatibili con la licenza Odbl, da parte dello Stato. Attendo ulteriori critiche/mancanze ;) Leonardo Il giorno 18 dicembre 2014 12:55, Andrea Musuruane musur...@gmail.com mailto:musur...@gmail.com ha scritto: 2014-12-17 18:51 GMT+01:00 Leonardo kinetocor...@gmail.com mailto:kinetocor...@gmail.com: Ho effettuato le modifiche richieste da te Andrea. :) Altri commenti/richieste? Se è tutto ok manderei l'email alla ML Import internazionale. Sempre io, anche se sarebbe bello che partecipasse anche qualcun altro :) In tagging plans deve essere scritto come vengono mappati i campi dello shapefile in quelli di osm. E' molto importante perché da qui si possono evidenziare eventuali problemi. Invece faccio molta fatica a seguire il processo. Tieni presente che un estraneo dovrebbe essere in grado di fare l'import al tuo posto e quindi deve avere tutti i passi necessari (alcuni possono anche arrivare più tardi, come gli script per ogr2osm). Inoltre, dovresti dire quali dati scaricare (basta il file strato03.zip?) ST03TE01CL01.dbf that has the street names (corrected with an ogr2osm script to normalize the names) Come avviene la normalizzazione? For city name i'll use the administration boundaries from [https://osm.wno-edv-service.de/boundaries/ | OSM Boundaries 1.6] and merge them from position on QGIS. Ma nei dati di origine non c'è la città? Perché io userei quel dato. Eviterei di basarmi su un'altra fonte di dati per capire a quale città si riferisce un civico (ci possono essere errori). For CAP i'll use the data from Italian Wikipedia entries for each cities. Questo non lo puoi fare perché la licenza di wikipedia non è compatibile con la ODbL. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org mailto:Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 21/12/2014 14:12, Leonardo ha scritto: Retromarcia sulla rimozione dei CAP: grazie a Fabrizio Tambussa, è stata fatta notare questa pagina web ( http://www.lineaamica.gov.it/opendata) del governo in cui ci sono tutti gli indirizzi della PA, comprendenti i CAP che mi servono per la Sardegna. I dati sono rilasciati in IODL 2.0, quindi perfettamente compatibili con la Odbl. Ho già aggiornato la pagina wiki dell'import in merito. Se non ci sono ulteriori critiche/mancanze nei prossimi giorni invierà la mail alla ML Import internazionale. Ciao e buone feste a tutti! Leonardo Buone feste anche a te, in lista se ne era già parlato di questi dati, con non poche polemiche sul fatto chenon sono georeferenziati. Ho controllato e vedendoli mi è venuto in mente che mancavano le coordinate, ed altri errori che non ricordo, se riesco a ritrovare la discussione te la posto. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUltA1AAoJEMTPIIVov0ZtAu4IAIAgei1XVtr3tlc4G9ybzip6 hTyxbLx3KSkbaHX8netG2qoGgnpJpG/tzj1Zk7+z3kpsSsicBO6WAaFYwp+c1UsX g+HuM2CbhpG0G9y8fV1qY7QSXs3ItNrgZADzKKG+3BSYVQldLIYp61uphhIY2F/q Z/DwlFe2CB+Y2Y1rXQFvt5Tcx4Npqc6IrgTt51i6lbnqAwSiKrhtGMEv6m6csev+ V3I74tBt/rCZP2jmIpN6ycjSJVcbHGFSX26WFeAOd83AxRk57nzWfRuJgLU3lFoj aspoSko+l3Rjb9yfatyBXLzsb5B2g7+ov4JULO7NBW+uxx+CPBkfMmBCTEcLllA= =xoXd -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Negozio di bomboniere
Giusta analisi Elena. Il giorno 21 dicembre 2014 13:10, Elena ``of Valhalla'' elena.valha...@gmail.com ha scritto: On 2014-12-17 at 18:57:35 +0100, Martin Koppenhoefer wrote: applicare dei tags (ben usati) che non descrivono ciò che si cerca di descrivere viene comunemente chiamato tagging for the renderer. E' vero che spesso il tagging richiede dal mappatore una valutazione (se il tag ancora va bene o non più), e in questo caso delle bomboniere trovo che si tratta di una tipologia molto diversa da quella descritta per shop=gift: Selling gifts, and/or greeting cards. This also covers tourist gifts, otherwise known as souvenir shops. In sostanza chi cerca un negozio di bomboniere non cerca un souvenir shop e vice versa. E poi ci sono 3 foto, per esempio: http://wiki.osm.org/wiki/File:Gift_shop_interior.jpg http://wiki.osm.org/wiki/Tag:shop%3Dgift ma proprio quella pagina specifica che shop=gift non è in generale un negozio di souvenir: A London tourist souvenir shop. Note: This is not really a quintessential example of a 'gift shop'. Dalla descrizione mi pare che sia più una cosa per cui gift shop è in generale il negozio che vende cose inutili, che poi si suddivide in categorie come cose inutili da dare ai festeggiati, cose inutili da dare agli invitati, cose inutili da usare per far sapere che si è viaggiato. -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 21/12/2014 14:50, girarsi_liste ha scritto: Buone feste anche a te, in lista se ne era già parlato di questi dati, con non poche polemiche sul fatto chenon sono georeferenziati. Ho controllato e vedendoli mi è venuto in mente che mancavano le coordinate, ed altri errori che non ricordo, se riesco a ritrovare la discussione te la posto. Dovrebbe essere questa: http://gis.19327.n5.nabble.com/Qualcosa-sui-civici-ISTAT-e-anche-uscita-td5800163.html - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUltJaAAoJEMTPIIVov0ZtVj0IAL6fMoGYDioC4MVBaXDS+vu0 0WmQBL7P0IpZwamdfdP5atmDKTrSFY85hfYZ9kgtTjwiUdVPngjWfImukSEB065s RoU8MPf62UlDFdaGzwcJVNjPo5QqKQhCnUmC90mzdG1+0M+8hzsU02m4JoSceGI9 DxwpX6RJqxMhXwHxkOCmoihRAbKmQZq4jMHuQKiocpJ1CG4sr24bBBRQB/rJZqhk wPJ8VdMgmWzaGjCUFS6wWg6nJewOhOln1LB8FtvTotVd1iUntVvsp2SVCeXbMzUu VS4WDUfc//ZbisRWIA8CHEQQTC/Gz4ibWAqqFfQv8sLxnxTdEwfYEv9GCuKo/84= =hr/S -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
Ma a me non interessa la georeferenziazione, solo il dato del cap presente nel csv. Il 21/dic/2014 15:00 girarsi_liste liste.gira...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 21/12/2014 14:50, girarsi_liste ha scritto: Buone feste anche a te, in lista se ne era già parlato di questi dati, con non poche polemiche sul fatto chenon sono georeferenziati. Ho controllato e vedendoli mi è venuto in mente che mancavano le coordinate, ed altri errori che non ricordo, se riesco a ritrovare la discussione te la posto. Dovrebbe essere questa: http://gis.19327.n5.nabble.com/Qualcosa-sui-civici-ISTAT-e-anche-uscita-td5800163.html - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUltJaAAoJEMTPIIVov0ZtVj0IAL6fMoGYDioC4MVBaXDS+vu0 0WmQBL7P0IpZwamdfdP5atmDKTrSFY85hfYZ9kgtTjwiUdVPngjWfImukSEB065s RoU8MPf62UlDFdaGzwcJVNjPo5QqKQhCnUmC90mzdG1+0M+8hzsU02m4JoSceGI9 DxwpX6RJqxMhXwHxkOCmoihRAbKmQZq4jMHuQKiocpJ1CG4sr24bBBRQB/rJZqhk wPJ8VdMgmWzaGjCUFS6wWg6nJewOhOln1LB8FtvTotVd1iUntVvsp2SVCeXbMzUu VS4WDUfc//ZbisRWIA8CHEQQTC/Gz4ibWAqqFfQv8sLxnxTdEwfYEv9GCuKo/84= =hr/S -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
Salve a tutti, scusatemi nel caso in cui non abbia capito nulla della questione (non sono pratico di import), ma riguardo ai CAP sardi dovrebbero esserci già tutti su OSM (almeno quelli dei comuni). Gli unici problematici sarebbero Cagliari e Sassari, dato che avendone le due città più di uno a testa non c'era la certezza di come inserirli (ci sono comunque, ma non so se possano essere esportati decentemente). Il Domenica 21 Dicembre 2014 16:21, Leonardo Frassetto kinetocor...@gmail.com ha scritto: Ma a me non interessa la georeferenziazione, solo il dato del cap presente nel csv.Il 21/dic/2014 15:00 girarsi_liste liste.gira...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 21/12/2014 14:50, girarsi_liste ha scritto: Buone feste anche a te, in lista se ne era già parlato di questi dati, con non poche polemiche sul fatto chenon sono georeferenziati. Ho controllato e vedendoli mi è venuto in mente che mancavano le coordinate, ed altri errori che non ricordo, se riesco a ritrovare la discussione te la posto. Dovrebbe essere questa: http://gis.19327.n5.nabble.com/Qualcosa-sui-civici-ISTAT-e-anche-uscita-td5800163.html - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUltJaAAoJEMTPIIVov0ZtVj0IAL6fMoGYDioC4MVBaXDS+vu0 0WmQBL7P0IpZwamdfdP5atmDKTrSFY85hfYZ9kgtTjwiUdVPngjWfImukSEB065s RoU8MPf62UlDFdaGzwcJVNjPo5QqKQhCnUmC90mzdG1+0M+8hzsU02m4JoSceGI9 DxwpX6RJqxMhXwHxkOCmoihRAbKmQZq4jMHuQKiocpJ1CG4sr24bBBRQB/rJZqhk wPJ8VdMgmWzaGjCUFS6wWg6nJewOhOln1LB8FtvTotVd1iUntVvsp2SVCeXbMzUu VS4WDUfc//ZbisRWIA8CHEQQTC/Gz4ibWAqqFfQv8sLxnxTdEwfYEv9GCuKo/84= =hr/S -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Actualizar Capas
Hola lo que yo entiendo es actualizar una capa de todos los buliding en bogota (dado el fin de la empresa donde trabaja), el inconveniente es que ya hay creados unos, lo mejor tal vez sea tomar la capa actual de bulding y comparar, supongo que como algunos datos de ideca.gov.co son abiertos ahor,a tal vez estara esta capa abierta. From: fredyriv...@gmail.com Date: Tue, 16 Dec 2014 10:39:10 -0500 To: talk-co@openstreetmap.org Subject: Re: [Talk-co] Actualizar Capas 2014-12-16 10:28 GMT-05:00 Oscar Jaimes oscar.jai...@mapasydatos.com: Buenos días, Hola Quiero saber como actualizo una capa de todo Bogotá, es la de construcciones? Por favor trata de ser mas especifico con lo que quieres, cuentanos cual es el problema que intentas resolver para ayudarte de la mejor manera. salu2 Muchas Gracias -- oscar.jai...@mapasydatos.com Oscar Jaimes vásquez Mapas y Datos S.A. ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co -- ## |___|__\___ | _ | |_ | } (_) (_) Twitter: @fredy_rivera Phone USA: (347) 688-4473 Mobil telephone: +57 3044886255 ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
[Talk-gb-westmidlands] Future planned works
As regards the paradise and other schemes like pinch point funding there are some rough timelines on this web site http://localview.birmingham.gov.uk/bham_connected/index.html I cannot say how up to date they will keep it as developers schedules slip, etc. Let me know if you need more info. Cheers, Stu ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-es] Mapping movilidad
Buenos días a todos, Decir que hay disponible un resumen de la Accessibility Mapping Party 3.0 publicado en la wiki de Geoinquietos Madrid [1]. Graeme ha añadido una nueva sección a la página principal (Otras actividades), y un enlace a una página nueva con el contenido del documento. Gracias Graeme. Un saludo navideño, Alay [1] http://wiki.osgeo.org/wiki/ACCESSIBILITY_MAPPING_PARTY_3.0. On 23 November 2014 00:14:06 CET, Santiago Higuera shigu...@osgeo.org wrote: Hola: Informaros que hoy se ha celebrado la sesión de toma de datos para la mapping de movilidad que anda 'empujando' y organizando Alay [1]. Ha estado bien, han asistido unas quince personas. Se han mapeado establecimientos en la zona de Latina. La semana próxima haremos la subida de datos a OpenStreetMap enseñando el tema de las etiquetas que hay que poner para lo de la accesibilidad. El jueves 27 se hará a las 17:30 en la Escuela de Topografía y el viernes a las 18:00 en Medialab, para los que no puedan ir el jueves. Estáis todos invitados Un saludo Santiago Higuera [1] http://www.adappgeo.net/blog/2014/11/accessibility-mapping-party-3-0/ ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es Alejandro Zappala___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
On 12/19/2014 08:39 PM, martinq wrote: 1) maxspeed ist eben als maximale (rechtliche) Höchstgeschwindigkeit definiert worden. Die Tatsache, dass der Wert von maxspeed in der Praxis nicht gefahren werden kann und für das Routing nicht immer passt, ist ein Problem von maxspeed selber -- und unabhängig von Signalanlagen. Versuche mit maxspeed:practical gibt es, so recht durchgesetzt hat es sich nicht (siehe letzter Absatz im Posting). Es geht mir nicht um praktische Geschwindigkeiten sondern um die rechtliche Begrenzung, die die meiste Zeit aktiv ist. In den überwiegenden Zahl von Fällen wird die maximale Höchstgeschwindigkeit für das Routing aber nicht so schlecht funktionieren, [...] Keine Frage. Aber an Stellen wie dem IGL auf der A1 in OÖ bei Linz ist imo die meiste Zeit ein 100er (ab Landesgrenze NÖ/OÖ bis zum Autobahnkreuz, wo sowieso immer 100 gilt) und die Maximalgeschwindigkeit dort wäre 130. Da bringt das Schema nichts, denn 130 wäre so oder so als Maximalgeschwindigkeit angegeben nur ist halt meistens die IGL Begrenzung aktiv. 2) Die maximale erlaubte Höchstgeschwindigkeit ist kein Schätzwert und wird auch nicht von der Verkehrsleitzentrale frei vergeben, sondern (so wie alle Verkehrszeichen) gesetzlich verordnet. - Daher gehört auch nicht der Wert hinein, der mit der Anlage technisch maximal möglich ist. Es gibt IGL Beschränkungen bspw. auf der A1 von der Landesgrenze NÖ/OÖ bis zum Knoten Linz oder auf der Tauernautobahn bei Sbg die nur zu Feiertagen abgeschaltet werden, wo ohnehin wenig Verkehr ist und wenn es gerade geregnet hat und windig ist, weil ausnahmsweise mal die Luft ausreichend sauber ist. Hier 130 zu erfassen ist zwar nach deiner Definition richtig, denn die Anlage gibt das her, aber es wird halt praktisch nie zutreffen. Weiteres Beispiel: Es gilt nun auf Teilabschnitten der Inntalautobahn immer IGL 100, weil neuerdings so verordnet, obwohl mit der Anlage die Beschränkung auch aufgehoben werden könnte -- maxspeed=100. Ortskundige Tiroler werden das sehr wohl wissen, ging ja auch durch die Medien. Die dazugehörige Verordnung https://www.tirol.gv.at/fileadmin/themen/umwelt/umweltrecht/LGBLA_TI_20141118_145.pdf musste dazu kaum jemand studieren... Ja genau darum geht's mir ja. Diesen 100er nicht erst zu erfassen, wenn es irgendeine Verordnung gibt die sagt wir schalten einfach nicht höher, sondern diesen 100er auch zu erfassen, wenn der 100er die deutlich häufigste Beschränkung an der Stelle ist. Ich würde also vorschlagen die niedrigere Geschwindigkeit zu erfassen, wenn die Signalanlage normalerweise die niedrigere Geschwindigkeit vorschreibt und nur selten auch nach oben korrigiert. tl;dr: Also ja, ich sehe eine Verbesserung wenn die absolute Maximalgeschwindigkeit einer Signalanlage erfasst wird, besonders auf den von dir angeführten Stadtautobahnen, wo tatsächlich niemals die 130 erreicht werden. Ich seh auch den Vorteil es in maxspeed einzutragen, da bestehende Datenkonsumenten alle Tags zur Signalanlage ignorieren können und einfach immer maxspeed auswerten können. Ich denke aber, wenn man sich schon drauf verlässt, dass Ortskundige die absolute Maximalgeschwindigkeit richtig wahrnehmen, dass Ortskundige die am häufigsten verordnete Geschwindigkeit noch besser wahrnehmen können (weil ja am häufigsten verordnet). Damit wäre die in den Daten angegebene erlaubte Höchstgeschwindigkeit meistens richtig und die Erfahrung von Ortskundigen, die ja ohnehin notwendig ist, würde sinnvoll in die Daten einfließen. Ich glaube, wenn man das maxspeed-Mapping wegen Signalanlagen ändern möchte, wäre das genau der richtige Zeitpunkt um eben auch die variablen Beschränkungen die eigentlich immer aktiv sind und nur deutlich seltener auch höhere Geschwindigkeiten zulassen, ordentlich erfassbar zu machen. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Am 21.12.2014 um 18:49 schrieb Norbert Wenzel: 1) maxspeed ist eben als maximale (rechtliche) Höchstgeschwindigkeit definiert worden. Die Tatsache, dass der Wert von maxspeed in der Praxis nicht gefahren werden kann und für das Routing nicht immer passt, ist ein Problem von maxspeed selber -- und unabhängig von Signalanlagen. Versuche mit maxspeed:practical gibt es, so recht durchgesetzt hat es sich nicht (siehe letzter Absatz im Posting). Es geht mir nicht um praktische Geschwindigkeiten sondern um die rechtliche Begrenzung, die die meiste Zeit aktiv ist. [...] Keine Frage. Aber an Stellen wie dem IGL auf der A1 in OÖ bei Linz ist imo die meiste Zeit ein 100er (ab Landesgrenze NÖ/OÖ bis zum Autobahnkreuz, wo sowieso immer 100 gilt) und die Maximalgeschwindigkeit dort wäre 130. Meiste Zeit ist zwar formal gesehen ein objektiver Ansatz, er ist aber in der Praxis deutlich schwerer zu erfassen [es ist ja schon die maximale Höchstgeschwindigkeit nicht ganz unproblematisch und benötigt einige Fahrten/Beobachtungen] und mit mehr Konflikten behaftet, weil die eigenen Autofahrten leider nicht gleichmäßig über die Zeit verteilt sind. Ebenso stellt sich die Frage des Beobachtungszeitraums, gerade beim IG-L. Im Winter wird's vermutlich schlimmer sein, ebenso am Tag vs. Nacht, ebenso gibt es jahreszeitlichen Schwankungen, Monate können daher unterschiedlich sein. Leider konnte ich keine IG-L Fakten über den Abschnitt A1 bei Linz finden, aber IG-L-Anlagen sind typischerweise nur 30%-50% der Zeit aktiv [gilt das nun als meiste Zeit?]. Für den durchschnittlichen Pendler kann sich das trotzdem wie 100% anfühlen, weil der fährt ja nicht in der Nacht, Samstag oder Sonntag, sondern in der Emissionsspitze am Morgen und Abend. Für den Fall A1 bei Linz kann es aber durchaus anders sein, ich hab' leider keine Daten dazu gefunden. Es stellt sich die Frage, ob man für Spezialfälle* eine problematischere 'maxspeed' Definition in Kauf nehmen will. Meiner Meinung nach müsste man das Problem mit einer Lösung für ein Default-Routing-Geschwindigkeits-Profil anpacken [ideal mit conditionals für Zeitabhängigkeiten, etc.], wenn diese Information überhaupt in die OSM-Datenbank gehört. Am Ende wäre es viel Aufwand mit (im Verhältnis zum Aufwand) wenig Genauigkeits-Verbesserung, weil die Verwendung von Echtzeit-Verkehrsdaten solche statischen Angaben wohl immer schlagen werden, wenn es um Fahrten im Berufsverkehr geht, bei denen eben die Fahrtzeit ein wichtiger Aspekt ist. OSM ohne weitere Datenquellen wird wohl auf absehbare Zeit mit machbarem Aufwand nur für Schönwetter-Sonntagsfahrten realistische Werte liefern können. * in Österreich, international muss das nicht so sein, aber alle Diskussionen und RFCs haben in der Richtung noch nichts ergeben. Gruß martinq Off-Topic: Ich bin beim Recherchieren auf folgenden Fun-Fact gestoßen: Ohne IG-L ist die tatsächlich gefahrene Durchschnittsgeschwindigkeit von PKWs 123 km/h, mit IG-L dem 100er 113 km/h... ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] Padání traceru
Ona je to dost vzácná chyba. Multipolygony totiž můžou obsahovat pouze cesty. Mě by úplně stačilo, kdyby tracer vyhodil upozornění ve stylu Multipolygon xxx obsahuje prvky špatného typu, ať vím, kde mám hledat :-) Michal -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: talk-cz@openstreetmap.org Datum: 20. 12. 2014 21:25:48 Předmět: Re: [Talk-cz] Padání traceru Jo, padá :-) Tuhle situaci jsem považoval za tak nepravděpodobnou, že ji tracer sice zjistí, ale nesnaží se to řešit a rovnou vyhodí výjimku Multipolygon neobsahující cesty nelze editovat. Nu, něco s tím udělám, vidím to poprvé. Martin On 20.12.2014 20:58, Martin Švec - OSM wrote: Ahoj, ufff, multipolygon co má jako člena jinou relaci? Takovou obskurnost by tracer měl ignorovat, ale asi ne úplně dokonale. Zkusím nasimulovat a opravit. Martin On 20.12.2014 20:36, Michal Pustějovský wrote: Zdravím, dneska při mapování lpis polí okoli Českého Těšína mi tracer začal znenadání padat. Začalo to vždy u stejného pole a po jedné vyhozené chybě už přestalo trasovat i ostatní pole. Po hodině hrátek s datasetem jsem zjistil pravděpodobný důvod. Chybu způsobuje, pokud je KDEKOLIV v datasetu relace lesa (multipolygon), která má za člena s rolí inner jinou relaci. Po opravení a restartu JOSM už vše trasovat šlo. Třeba to někomu pomůže. Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Duchove v Kozojedech. Re: Osmose Česká republika
Dne 21.12.2014 v 22:25 Pavel Machek napsal(a): Ahoj! Pavle, za nějaké zjišťování budu rád. Pokud pošlete konkrétní zjištění i s fotkami, bude to fajn. Petr Souček Tak sorry, na foceni nakonec nebyl cas, prostor a svetlo. Sli jsme ze severu po cervene znacce skrz chatky; na mnoha nebylo nic, kdyz tam neco bylo, tak to bila cerna cisla na zlutym podklade. Prvni chatka mela snad 04, pak tam byla chatka 074, a par dalsich. Vsechna cisla 100, zajimavy je ze dost z nich melo 0 na zacatku. Snad to pomuze, Pavel Ta nula na začátku je jen jiný zápis čísla evidenčního. http://cs.wikipedia.org/wiki/Ozna%C4%8Dov%C3%A1n%C3%AD_dom%C5%AF#mediaviewer/File:Osada_Kaz%C3%ADn,_eviden%C4%8Dn%C3%AD_%C4%8D%C3%ADslo_0359.jpg Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-it-southtyrol] Hiking relations and mapping suggestions
[since the last conversation switched to english, I'll start directly with it] This is a rather practical question about keeping details/data to map hiking relations. I'd like to know how others are doing it and see if there's a better way. I was able to map all the hiking relations starting from Oberinn/Wangen: http://map.gegg.us/?zoom=12lat=46.49848lon=11.3355layers=BFFTTFF this includes also many other partial relations from Oberinn towards Tann/Klobenstein/Oberbozen/... of which I still don't have enough knowledge to verify the entire relation. Whenever I pass in front of a hiking guidepost and/or a relevant detail of the hiking trail I take a geotagged photo. So far, I have more than 250 photos of the area (~100 guideposts), including countless gps tracks. Whenever I can see (from the previous guideposts photos) that I have the entire hiking path (verified from start to finish) I add the hiking relation and complete it. I've also started to add partial relations for guideposts I've passed-by, since I realized it's easier for others to see where the hiking paths are going through. In this case I mark the relation with a fixme, and I also started to mark with a fixme the last known node of the relation. Unfortunately, without the photos themselves, it's sometimes still hard, for somebody else, to understand where exactly a path ends. I've also uploaded several gps tracks, though I found later that without photos they are also mostly useless due to the poor resolution of the gps, and also due to the massive editing required for a meaningful track (I've taken the habit to just cut-through the woods/terrain to go towards the regions I'm mapping). That being said, I upload them if I followed a known path from start to finish. At this point I'm wondering if there's something we can do to upload these geotagged photos somewhere. They are incredibly useful for those that are willing to complete the hiking relations. Not to mention that it's also countless hours of actual hiking involved... Ideas? ___ Talk-it-southtyrol mailing list Talk-it-southtyrol@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-southtyrol
Re: [OSM-talk-fr] DKIM Re: Démo recherche d'adresse / POI (Jour de Fête)
Bonjour, Il y a un petit bug avec les virgules. Sans la virgule ça passe. Faudra que je regarde c'est pas grand chose à corriger. Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Demo-recherche-d-adresse-POI-Jour-de-Fete-tp5820413p5827882.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo recherche d'adresse / POI (Jour de Fête)
C'est qui ce Pierre Mandes-France, qu'OSM.or me trouve me trouve à Cadirac (Ariège) et Limoge, et qui est un quasi-homonyme du célèbre Mendès-France (http://fr.wikipedia.org/wiki/Pierre_Mend%C3%A8s_France ) ? Art. Le 20 décembre 2014 10:51, Cyrille Giquello cyrill...@gmail.com a écrit : Étonnant ! Sur osm.org aucun résultat pour rue pierre mandes france, Limoge. Sur http://dev.geovelo.fr/jdf/ il y a des propositions, dont la bonne rue Rue Pierre Mandés-France, Limoges. Ne pourrait-on pas avoir ce moteur de recherche sur http://tile.openstreetmap.fr/ ? Le 15 octobre 2014 18:52, GaelADT gael.sauva...@gmail.com a écrit : Bonjour, Nous en avions parlé rapidement lors de SotM France : nous (Géovélo Luc Léger, contributeur OSM) travaillons depuis quelque temps sur un système de recherche de rue / POI / etc. Ce projet s'appelle pour le moment Jour de Fête : https://github.com/lluc/django_jdf Un site de démo a été mis en place histoire de donner une idée à tout le monde, avec les données France (pas forcément super à jour) : http://dev.geovelo.fr/jdf/ Attention ce n’est pas fait pour de la production: le serveur peut donc potentiellement être un peu long à retourner des résultats. Et il reste encore pas mal de soucis à régler, mais c’est un début. Pour faire simple : il n'y a aucun outil suffisamment ergonomique, libre, pour qu'un utilisateur lambda trouve un objet sur OSM, si possible avec de l'auto-complétion. Si bien qu'aujourd’hui beaucoup de services utilisent Google pour la recherche d’adresse ou de POI. Ce que nous avons fait n'est pas forcément un truc révolutionnaire, mais nous espérons que cela sera une nouvelle étape pour rendre OSM plus accessible en France et que cela ferra enfin bouger les choses niveau geocoding (chez Géovélo on en a marre d'utiliser l'API Google pour l'autocomplétion !) Voici ce qu'est aujourd'hui Jour de Fête : - un projet libre qui est basé sur les données d'un import Nominatim, - recherche phonétique d'objet OSM (avenue edouar michelin sera reconnu), - reconnaissance sémantique (rue edouard michelin sera reconnu, même s’il existe uniquement avenue edouard michelin), - un outil entièrement configurable : on peut choisir les tags OSM qui doivent être reconnus (une option existe pour tout sortir), on peut choisir dans quel ordre doivent sortir les résultats (exemple les villes avant les rues, etc.). Exemples concrets d’utilisation : - rechercher uniquement les rues (ou tout autre chose) sur le territoire d’une commune, - rechercher uniquement les gares, arrêts de bus, de tramway, de métro et les ordonner (d’abord les gares, puis les arrêts, etc.) - et bien sur notre exemple pour Géovélo faire une recherche d’adresse / POI fine en choisissant précisément les types de POI que l’on veut faire remonter et dans quel ordre (commune avant quartier, quartier avant avenue, gare avant magasin, etc.) Ce qu'il reste à faire / Roadmap : - optimiser les temps de réponse, voir ce que cela donne sur un serveur digne de ce nom, - recherche partielle (zola tours sera reconnue) - forcer la recherche sur une bounding box - ajouter les numéros de rue : Faire un lien vers BANO ? - améliorer l'ordonnancement des résultats - faire une mise à jour des données via les diff de OSM (la mise à jour des données prend 1 heure pour la France actuellement) Voilà merci d’avance pour vos retours. Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Demo-recherche-d-adresse-POI-Jour-de-Fete-tp5820413.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche QA malade ?
En passant, serait il possible sur la couche QA de mettre en évidence - peut etre en séparant les couche - les zone a mappée. Elle se retrouve caché sous les point commune/cadastre au faible zoom et on a du mal a prendre conscience de l'ampleur du travail qu'il reste a faire pour mapper rien que les voies qui conduisent aux habitations... Plus je mappe les rue avec le mapcraft BANO plus je m'apercoit qu'il manque quantité de voies surtout a la campagne!!! Mais vraiment beaucoup. Le 19 décembre 2014 17:01, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, quelques pépins avec QA qui me bouffe bien trop de temps de calculs. Je vais avoir un peu de temps dispo sur les 2 semaines qui viennent pour m'y pencher plus sérieusement... 2014-12-19 14:41 GMT+01:00 JB jb...@mailoo.org: La couche QA ne supporte pas la pluie ? On a perdu plein d'information, aujourd'hui (mais je ne sais pas de quand ça date) : http://tile.openstreetmap.fr/?zoom=9lat=47.97976lon=4. 75217layers=B000TFF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche QA malade ?
Ou mieux une heatmap des zone a mapper... Le 21 décembre 2014 14:04, Tetsuo Shima tets...@gmail.com a écrit : En passant, serait il possible sur la couche QA de mettre en évidence - peut etre en séparant les couche - les zone a mappée. Elle se retrouve caché sous les point commune/cadastre au faible zoom et on a du mal a prendre conscience de l'ampleur du travail qu'il reste a faire pour mapper rien que les voies qui conduisent aux habitations... Plus je mappe les rue avec le mapcraft BANO plus je m'apercoit qu'il manque quantité de voies surtout a la campagne!!! Mais vraiment beaucoup. Le 19 décembre 2014 17:01, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, quelques pépins avec QA qui me bouffe bien trop de temps de calculs. Je vais avoir un peu de temps dispo sur les 2 semaines qui viennent pour m'y pencher plus sérieusement... 2014-12-19 14:41 GMT+01:00 JB jb...@mailoo.org: La couche QA ne supporte pas la pluie ? On a perdu plein d'information, aujourd'hui (mais je ne sais pas de quand ça date) : http://tile.openstreetmap.fr/?zoom=9lat=47.97976lon=4. 75217layers=B000TFF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche QA malade ?
Je pense revoir le mode de génération de ce rendu. Actuellement un gros croisement est fait entre les données OSM et les carreaux de l'INSEE... c'est à dire des millions d'objets croisées avec des millions d'objets. J'envisage pour chaque carreau INSEE, de maintenir son état de couverture dans OSM. Il serait possible de ne mettre à jour que ceux qui avaient été détectés comme incomplets, car c'est bien rare qu'on supprime des données. Plus on avance, moins il y aura de carreaux à vérifier, alors qu'il y a de plus en plus de données. Devoirs de vacances ;) Le 21 décembre 2014 14:05, Tetsuo Shima tets...@gmail.com a écrit : Ou mieux une heatmap des zone a mapper... Le 21 décembre 2014 14:04, Tetsuo Shima tets...@gmail.com a écrit : En passant, serait il possible sur la couche QA de mettre en évidence - peut etre en séparant les couche - les zone a mappée. Elle se retrouve caché sous les point commune/cadastre au faible zoom et on a du mal a prendre conscience de l'ampleur du travail qu'il reste a faire pour mapper rien que les voies qui conduisent aux habitations... Plus je mappe les rue avec le mapcraft BANO plus je m'apercoit qu'il manque quantité de voies surtout a la campagne!!! Mais vraiment beaucoup. Le 19 décembre 2014 17:01, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, quelques pépins avec QA qui me bouffe bien trop de temps de calculs. Je vais avoir un peu de temps dispo sur les 2 semaines qui viennent pour m'y pencher plus sérieusement... 2014-12-19 14:41 GMT+01:00 JB jb...@mailoo.org: La couche QA ne supporte pas la pluie ? On a perdu plein d'information, aujourd'hui (mais je ne sais pas de quand ça date) : http://tile.openstreetmap.fr/?zoom=9lat=47.97976lon=4. 75217layers=B000TFF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Bonjour à tous, Je souhaiterai finaliser l'import des numéros de maisons d'une ville, il ne me reste qu'une seule rue https://www.openstreetmap.org/way/27407361. Malheureusement, au moment de l'upload vers OSM, je me retrouve avec 140 conflits de version : il y a vingt jours, j'ai fait quelques modifications dans cette zone. Ces modifications n'ont toujours pas été prises en compte au niveau de http://cadastre.openstreetmap.fr. Comment faire, à part résoudre les 140 conflits ? Savez-vous à quelle fréquence est mise à jour la base OSM utilisée par l'outil d'import des adresses http://cadastre.openstreetmap.fr/?type=adresses ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Le 21 déc. 2014 à 16:06, Yoann Cornec yoanncor...@gmail.com a écrit : Ces modifications n'ont toujours pas été prises en compte au niveau de http://cadastre.openstreetmap.fr http://cadastre.openstreetmap.fr/. Les modifications faites dans OSM restent dans OSM. Le cadastre sert à importer les bâtiments au lieu de les dessiner à la main. Comment faire, à part résoudre les 140 conflits ? Savez-vous à quelle fréquence est mise à jour la base OSM utilisée par l'outil d'import des adresses http://cadastre.openstreetmap.fr/?type=adresses ? Quand le cadastre est mis à jour, c’est à dire une fois par an (seulement). Si j’ai tout compris, la page « fantoir »indique la date du dernier téléchargement du cadastre dans le serveur OSM France : http://cadastre.openstreetmap.fr/fantoir/#insee=74001 http://cadastre.openstreetmap.fr/fantoir/#insee=74001 — Yves PS: Est-il possible d’afficher cette même date sur la page du cadastre ?___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Le 21 décembre 2014 16:14, Yves Pratter yves.prat...@gmail.com a écrit : Le 21 déc. 2014 à 16:06, Yoann Cornec yoanncor...@gmail.com a écrit : Ces modifications n'ont toujours pas été prises en compte au niveau de http://cadastre.openstreetmap.fr. Les modifications faites dans OSM restent dans OSM. Le cadastre sert à importer les bâtiments au lieu de les dessiner à la main. Pas que, pas que... l'outil d'extraction permet aussi de récupérer les adresses pour les intégrer. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
J'ai dû mal m'exprimer. Je ne parle pas de la mise à jour du cadastre, mais de celle de la base OSM utilisée par http://cadastre.openstreetmap.fr/adresses. L'outil d'import des adresses récupère certains bâtiments pour coller les nœuds d'adresse directement en façade http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses#Situation_de_l.27adresse . Ce sont ces bâtiments qui ne sont plus à jour par rapport à la base osm.org. Quand est-ce que cadastre.openstreetmap.fr actualisera sa base OSM ? Le 21 décembre 2014 16:19, Christian Quest cqu...@openstreetmap.fr a écrit : Le 21 décembre 2014 16:14, Yves Pratter yves.prat...@gmail.com a écrit : Le 21 déc. 2014 à 16:06, Yoann Cornec yoanncor...@gmail.com a écrit : Ces modifications n'ont toujours pas été prises en compte au niveau de http://cadastre.openstreetmap.fr. Les modifications faites dans OSM restent dans OSM. Le cadastre sert à importer les bâtiments au lieu de les dessiner à la main. Pas que, pas que... l'outil d'extraction permet aussi de récupérer les adresses pour les intégrer. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Pas que, pas que... l'outil d'extraction permet aussi de récupérer les adresses pour les intégrer. Il y avait un entre autres » caché sous un espace ;-D Le 21 déc. 2014 à 16:30, Yoann Cornec yoanncor...@gmail.com a écrit : Je ne parle pas de la mise à jour du cadastre, mais de celle de la base OSM utilisée par http://cadastre.openstreetmap.fr/adresses http://cadastre.openstreetmap.fr/adresses. La base de données OSM est sur le serveur international (on fait nos édition dessus). Ensuite il y a une mise à jour automatique de la base du serveur OSM France qui gère l’outil cadastre. Normalement ça se fait en quelques minutes pour générer les tuiles françaises mais il y a parfois des latences assez importantes. Pour Fantoir il est rafraîchit automatiquement toutes les 24h (et depuis peu à la demande). Tu peux voir la date de mise à jour de la base du serveur OSM France au même endroit : 21-12-2014 01:34:20 Christian, à quelle période est rafraîchie la base qu’utilise le cadastre ? — Yves PS: le mécanisme en général de synchronisation des serveurs à une fréquence de mise à jour par minutes, heures, jours, (ou manuelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Opendata... kinenveu ?
Deux jeux de données intéressants sur l'agglo de St Malo: - les arrêts de bus: https://www.data.gouv.fr/fr/datasets/emplacement-des-arrets-de-bus-du-reseau-transport-saint-malo-agglomeration-2/ - les casse bouteilles : https://www.data.gouv.fr/fr/datasets/points-dapport-volontaire-shp/ Mais aussi, sur la Ville de St Malo... - un parcours touristique: https://www.data.gouv.fr/fr/datasets/suivez-lhermine/ - les cimetières: https://www.data.gouv.fr/fr/datasets/cimetieres-malouins/ - les campings: https://www.data.gouv.fr/fr/datasets/campings/ - les monuments: https://www.data.gouv.fr/fr/datasets/monuments-historiques-classes-a-saint-malo/ - les stations service: https://www.data.gouv.fr/fr/datasets/emplacement-des-stations-service-a-saint-malo-1/ - les défibrillateurs: https://www.data.gouv.fr/fr/datasets/defibrillateurs-1/ - les postes de secours: https://www.data.gouv.fr/fr/datasets/postes-de-secours/ - les zones de mouillage: https://www.data.gouv.fr/fr/datasets/zones-de-mouillages/ - les bureaux de vote: https://www.data.gouv.fr/fr/datasets/emplacement-des-bureaux-de-vote/ Et aussi des POI du Comité Départemental de l'Aube (restaurant, hotellerie, patrimoine culturel, équipements sportifs, etc): https://www.data.gouv.fr/fr/datasets/etablissements-touristiques-de-laube-en-champagne/ -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Le 21 décembre 2014 16:30, Yoann Cornec yoanncor...@gmail.com a écrit : J'ai dû mal m'exprimer. Je ne parle pas de la mise à jour du cadastre, mais de celle de la base OSM utilisée par http://cadastre.openstreetmap.fr/adresses. L'outil d'import des adresses récupère certains bâtiments pour coller les noeuds d'adresse directement en façade http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses#Situation_de_l.27adresse . Ce sont ces bâtiments qui ne sont plus à jour par rapport à la base osm.org. Quand est-ce que cadastre.openstreetmap.fr actualisera sa base OSM ? En principe ça se fait en live... sur une base qui actuellement n'a pas de retard (celle d'osm105 alias layers). Bizarre... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche QA malade ?
Le dimanche 21 décembre 2014 à 15:13 +0100, Christian Quest a écrit : Je pense revoir le mode de génération de ce rendu. Actuellement un gros croisement est fait entre les données OSM et les carreaux de l'INSEE... c'est à dire des millions d'objets croisées avec des millions d'objets. il y a 25% des batiments avec wall=no ... un batiment leger n'a pas necessairement d'habitant ? J'envisage pour chaque carreau INSEE, de maintenir son état de couverture dans OSM. Il serait possible de ne mettre à jour que ceux qui avaient été détectés comme incomplets, car c'est bien rare qu'on supprime des données. Plus on avance, moins il y aura de carreaux à vérifier, alors qu'il y a de plus en plus de données. rien n'empeche de faire les 2 ... le 1er du mois, analyse complete les autres jours un diff Devoirs de vacances ;) vacances = procrastination+ : pourquoi faire aujourd'hui ce que quelqu'un autre peut faire a ta place demain Le 21 décembre 2014 14:05, Tetsuo Shima tets...@gmail.com a écrit : Ou mieux une heatmap des zone a mapper... Le 21 décembre 2014 14:04, Tetsuo Shima tets...@gmail.com a écrit : En passant, serait il possible sur la couche QA de mettre en évidence - peut etre en séparant les couche - les zone a mappée. Elle se retrouve caché sous les point commune/cadastre au faible zoom et on a du mal a prendre conscience de l'ampleur du travail qu'il reste a faire pour mapper rien que les voies qui conduisent aux habitations... Plus je mappe les rue avec le mapcraft BANO plus je m'apercoit qu'il manque quantité de voies surtout a la campagne!!! Mais vraiment beaucoup. Le 19 décembre 2014 17:01, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, quelques pépins avec QA qui me bouffe bien trop de temps de calculs. Je vais avoir un peu de temps dispo sur les 2 semaines qui viennent pour m'y pencher plus sérieusement... 2014-12-19 14:41 GMT+01:00 JB jb...@mailoo.org: La couche QA ne supporte pas la pluie ? On a perdu plein d'information, aujourd'hui (mais je ne sais pas de quand ça date) : http://tile.openstreetmap.fr/?zoom=9lat=47.97976lon=4.75217layers=B000TFF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo recherche d'adresse / POI (Jour de Fête)
Hello Photon ne fonctionne pas bien ? http://photon.komoot.de/ Stf Le 15/10/2014 18:52, GaelADT a écrit : Bonjour, Nous en avions parlé rapidement lors de SotM France : nous (Géovélo Luc Léger, contributeur OSM) travaillons depuis quelque temps sur un système de recherche de rue / POI / etc. Ce projet s'appelle pour le moment Jour de Fête : https://github.com/lluc/django_jdf Un site de démo a été mis en place histoire de donner une idée à tout le monde, avec les données France (pas forcément super à jour) : http://dev.geovelo.fr/jdf/ Attention ce n’est pas fait pour de la production: le serveur peut donc potentiellement être un peu long à retourner des résultats. Et il reste encore pas mal de soucis à régler, mais c’est un début. Pour faire simple : il n'y a aucun outil suffisamment ergonomique, libre, pour qu'un utilisateur lambda trouve un objet sur OSM, si possible avec de l'auto-complétion. Si bien qu'aujourd’hui beaucoup de services utilisent Google pour la recherche d’adresse ou de POI. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Là, elle a au moins 20 jours de retard. Est-ce que le script ne conserverai pas des données osm de précédentes exécutions en cache ? Mes modifs non prises en compte ont été faites après la première extraction des adresses de cette ville. Le 21 décembre 2014 16:52, Christian Quest cqu...@openstreetmap.fr a écrit : Le 21 décembre 2014 16:30, Yoann Cornec yoanncor...@gmail.com a écrit : J'ai dû mal m'exprimer. Je ne parle pas de la mise à jour du cadastre, mais de celle de la base OSM utilisée par http://cadastre.openstreetmap.fr/adresses. L'outil d'import des adresses récupère certains bâtiments pour coller les nœuds d'adresse directement en façade http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses#Situation_de_l.27adresse . Ce sont ces bâtiments qui ne sont plus à jour par rapport à la base osm.org. Quand est-ce que cadastre.openstreetmap.fr actualisera sa base OSM ? En principe ça se fait en live... sur une base qui actuellement n'a pas de retard (celle d'osm105 alias layers). Bizarre... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo recherche d'adresse / POI (Jour de Fête)
Photon n'intègre pas les adresses de BANO à ce qu'il me semble... Le 21 décembre 2014 17:03, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Hello Photon ne fonctionne pas bien ? http://photon.komoot.de/ Stf Le 15/10/2014 18:52, GaelADT a écrit : Bonjour, Nous en avions parlé rapidement lors de SotM France : nous (Géovélo Luc Léger, contributeur OSM) travaillons depuis quelque temps sur un système de recherche de rue / POI / etc. Ce projet s'appelle pour le moment Jour de Fête : https://github.com/lluc/django_jdf Un site de démo a été mis en place histoire de donner une idée à tout le monde, avec les données France (pas forcément super à jour) : http://dev.geovelo.fr/jdf/ Attention ce n'est pas fait pour de la production: le serveur peut donc potentiellement être un peu long à retourner des résultats. Et il reste encore pas mal de soucis à régler, mais c'est un début. Pour faire simple : il n'y a aucun outil suffisamment ergonomique, libre, pour qu'un utilisateur lambda trouve un objet sur OSM, si possible avec de l'auto-complétion. Si bien qu'aujourd'hui beaucoup de services utilisent Google pour la recherche d'adresse ou de POI. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] DKIM Re: Mise à jour cadastre.openstreetmap.fr
Bonsoir Yoann, Le 21/12/2014 17:06, Yoann Cornec a écrit : Là, elle a au moins 20 jours de retard. Est-ce que le script ne conserverai pas des données osm de précédentes exécutions en cache ? Mes modifs non prises en compte ont été faites après la première extraction des adresses de cette ville. Et tu as rejoué l'extraction récemment, mais sans bénéficier des mises à jour ? Je viens de regarder et on n'a pas de cache, du moins en théorie. Si tu peux m'indiquer la commune, je regarde ça ce soir. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] GPS (routier) hors-ligne en HTML5
Le 20 décembre 2014 14:48, Landry Breuil landry.bre...@gmail.com a écrit : 2014-12-20 11:21 GMT+01:00 Guilhem Bonnefille guilhem.bonnefi...@gmail.com: Bonjour, Ayant fait rentrer Firefox OS à la maison, je m'interroge actuellement sur l'utilisation de ce système vis à vis d'OSM. Coté GPS, le système (vendu par Leclerc) est équipé d'une application Here. https://marketplace.firefox.com/app/here-maps-packaged?src=search Celle-ci est propriétaire, fonctionne essentiellement en ligne, même si elle offre la possibilité de pré-télécharger des zones pour fonctionner hors-ligne. Quand on cherche sur le market, on trouve d'autres applications en lien avec la carto. https://marketplace.firefox.com/category/maps-navigation Mais pour l'essentiel, elles fonctionnent toutes en mode connecté. Je m'interroge alors sur la manière de proposer une application fonctionnant réellement hors-ligne, c'est à dire qu'on ne soit pas obligé d'anticiper un déplacement : les données doivent être présentes dans le périphérique, comme tout GPS routier. J'ai aussi un ffxos phone (zte open première génération) depuis un an comme seul portable, et la seule killer-app qui me manque par rapport a android est l'équivalent d'OSMand. Autant stocker/manipuler/afficher du mbtiles est pratique et envisageable relativement simplement, le gros plus d'OSMand et de son modèle 'pack de données par région': c'est du vectoriel, et comme le rappelle frédéric : - c'est routable/requêtable - c'est plus léger que du raster Après, evidemment afficher du vectoriel a la volée, c'est *gourmand* en perfs - c'est aussi pour ca qu'OSMand est bien foutu, l'alternative '3g-affiche du raster - fluide mais basique' vs 'offline-fallback sur vectoriel - gourmand mais plus puissant'... Du coup, envisager de réutiliser le format d'OSMand serait le top, mais ca veut dire qu'il faut parser en JS, alors qu'OSMand est nativement en java.. tout à refaire. C'est effectivement suite à ces réflexions que je m'interroge sur la taille occupée par un format tuile. En effet, autant la CPU embarquée est chère, autant l'espace de stockage semble abordable (carte SD 4Go ou 8Go). De plus, comme vous avez pu le constater sur les liens que j'ai fourni, ou en fouillant dans le market, il semble que plusieurs pistes aient déjà été creusées (leaflet online, téléchargement de régions avant le voyage, routage offline à partir d'un GPX pré-chargé...) A mon avis, il reste à évaluer la piste de pack pré-packagés en raster et peut-être aussi en vecteur. Ensuite, il sera possible d'assembler toutes ces pistes pour construire un OSMand à la HTML5. Perso, je ne sais absolument pas comment évaluer la volumétrie d'une solution de stockage en tuile. Et c'est pour cela que je m'adresse à vous. Par exemple, les réponses aux questions suivantes peuvent aider à évaluer objectivement la pérénité d'une telle solution : - quel niveau de zoom permet de couvrir la France avec une occupation de 1Go ? - quelle zone est couverte au niveau 18 pour 1Go ? Si quelqu'un a des infos chiffrées sur le sujet, ça pourrait beaucoup aider. Merci d'avance. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] GPS (routier) hors-ligne en HTML5
Le 21 décembre 2014 20:32, Guilhem Bonnefille guilhem.bonnefi...@gmail.com a écrit : Le 20 décembre 2014 14:48, Landry Breuil landry.bre...@gmail.com a écrit : 2014-12-20 11:21 GMT+01:00 Guilhem Bonnefille guilhem.bonnefi...@gmail.com: Bonjour, Ayant fait rentrer Firefox OS à la maison, je m'interroge actuellement sur l'utilisation de ce système vis à vis d'OSM. Coté GPS, le système (vendu par Leclerc) est équipé d'une application Here. https://marketplace.firefox.com/app/here-maps-packaged?src=search Celle-ci est propriétaire, fonctionne essentiellement en ligne, même si elle offre la possibilité de pré-télécharger des zones pour fonctionner hors-ligne. Quand on cherche sur le market, on trouve d'autres applications en lien avec la carto. https://marketplace.firefox.com/category/maps-navigation Mais pour l'essentiel, elles fonctionnent toutes en mode connecté. Je m'interroge alors sur la manière de proposer une application fonctionnant réellement hors-ligne, c'est à dire qu'on ne soit pas obligé d'anticiper un déplacement : les données doivent être présentes dans le périphérique, comme tout GPS routier. J'ai aussi un ffxos phone (zte open première génération) depuis un an comme seul portable, et la seule killer-app qui me manque par rapport a android est l'équivalent d'OSMand. Autant stocker/manipuler/afficher du mbtiles est pratique et envisageable relativement simplement, le gros plus d'OSMand et de son modèle 'pack de données par région': c'est du vectoriel, et comme le rappelle frédéric : - c'est routable/requêtable - c'est plus léger que du raster Après, evidemment afficher du vectoriel a la volée, c'est *gourmand* en perfs - c'est aussi pour ca qu'OSMand est bien foutu, l'alternative '3g-affiche du raster - fluide mais basique' vs 'offline-fallback sur vectoriel - gourmand mais plus puissant'... Du coup, envisager de réutiliser le format d'OSMand serait le top, mais ca veut dire qu'il faut parser en JS, alors qu'OSMand est nativement en java.. tout à refaire. C'est effectivement suite à ces réflexions que je m'interroge sur la taille occupée par un format tuile. En effet, autant la CPU embarquée est chère, autant l'espace de stockage semble abordable (carte SD 4Go ou 8Go). De plus, comme vous avez pu le constater sur les liens que j'ai fourni, ou en fouillant dans le market, il semble que plusieurs pistes aient déjà été creusées (leaflet online, téléchargement de régions avant le voyage, routage offline à partir d'un GPX pré-chargé...) A mon avis, il reste à évaluer la piste de pack pré-packagés en raster et peut-être aussi en vecteur. Ensuite, il sera possible d'assembler toutes ces pistes pour construire un OSMand à la HTML5. Perso, je ne sais absolument pas comment évaluer la volumétrie d'une solution de stockage en tuile. Et c'est pour cela que je m'adresse à vous. Par exemple, les réponses aux questions suivantes peuvent aider à évaluer objectivement la pérénité d'une telle solution : - quel niveau de zoom permet de couvrir la France avec une occupation de 1Go ? - quelle zone est couverte au niveau 18 pour 1Go ? Si quelqu'un a des infos chiffrées sur le sujet, ça pourrait beaucoup aider. Merci d'avance. Peut-être un début d'info. Au format PBF (vecteur) je trouve : - Afrique : 700 Mo - Antartique : 23 Mo - Asie : 3 Go - Australie Oceanie : 300 Mo - Amérique Centrale : 200 Mo - Europe : 14 Go - Amérique du Nord : 6 Go - Amérique du Sub : 600 Mo Tiré de http://download.geofabrik.de/ En plus, il semblerait qu'il y ait une lib en javascript : https://github.com/marook/osm-read Faut vraiment que je trouve un générateur à temps libre. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Le 21/12/2014 18:47, Vincent de Château-Thierry a écrit : Le 21/12/2014 17:06, Yoann Cornec a écrit : Là, elle a au moins 20 jours de retard. Est-ce que le script ne conserverai pas des données osm de précédentes exécutions en cache ? Mes modifs non prises en compte ont été faites après la première extraction des adresses de cette ville. Et tu as rejoué l'extraction récemment, mais sans bénéficier des mises à jour ? Je viens de regarder et on n'a pas de cache, du moins en théorie. Si tu peux m'indiquer la commune, je regarde ça ce soir. Possible que les soucis soient liés à l'overpass FR. J'ai basculé les traitements sur l'Overpass DE (overpass-api.de) et j'ai des résultats différents et cohérents. Si tu peux ré-essayer ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] GPS (routier) hors-ligne en HTML5
Salut, La taille des tuiles dépend du format de fichier et du niveau de détails (par exemple aplats de couleur vs dégradés de couleur). Les tuiles OSM en PNG pèsent grosso modo entre 10 et 50 ko selon le niveau de détail, disons 30 ko pour des estimations. Pour 1Go, on a donc droit à 1 000 000 / 30 ~ 35 000 tuiles Pour la France, ça correspond environ aux tuiles du zoom 0 au zoom 12 inclus. Pour aller jusqu'au zoom 18, tu as droit à une zone de 0.2 * 0.2° environ, à peu près 20km * 20km. Fred Le 21 décembre 2014 20:32, Guilhem Bonnefille guilhem.bonnefi...@gmail.com a écrit : Le 20 décembre 2014 14:48, Landry Breuil landry.bre...@gmail.com a écrit : 2014-12-20 11:21 GMT+01:00 Guilhem Bonnefille guilhem.bonnefi...@gmail.com: Bonjour, Ayant fait rentrer Firefox OS à la maison, je m'interroge actuellement sur l'utilisation de ce système vis à vis d'OSM. Coté GPS, le système (vendu par Leclerc) est équipé d'une application Here. https://marketplace.firefox.com/app/here-maps-packaged?src=search Celle-ci est propriétaire, fonctionne essentiellement en ligne, même si elle offre la possibilité de pré-télécharger des zones pour fonctionner hors-ligne. Quand on cherche sur le market, on trouve d'autres applications en lien avec la carto. https://marketplace.firefox.com/category/maps-navigation Mais pour l'essentiel, elles fonctionnent toutes en mode connecté. Je m'interroge alors sur la manière de proposer une application fonctionnant réellement hors-ligne, c'est à dire qu'on ne soit pas obligé d'anticiper un déplacement : les données doivent être présentes dans le périphérique, comme tout GPS routier. J'ai aussi un ffxos phone (zte open première génération) depuis un an comme seul portable, et la seule killer-app qui me manque par rapport a android est l'équivalent d'OSMand. Autant stocker/manipuler/afficher du mbtiles est pratique et envisageable relativement simplement, le gros plus d'OSMand et de son modèle 'pack de données par région': c'est du vectoriel, et comme le rappelle frédéric : - c'est routable/requêtable - c'est plus léger que du raster Après, evidemment afficher du vectoriel a la volée, c'est *gourmand* en perfs - c'est aussi pour ca qu'OSMand est bien foutu, l'alternative '3g-affiche du raster - fluide mais basique' vs 'offline-fallback sur vectoriel - gourmand mais plus puissant'... Du coup, envisager de réutiliser le format d'OSMand serait le top, mais ca veut dire qu'il faut parser en JS, alors qu'OSMand est nativement en java.. tout à refaire. C'est effectivement suite à ces réflexions que je m'interroge sur la taille occupée par un format tuile. En effet, autant la CPU embarquée est chère, autant l'espace de stockage semble abordable (carte SD 4Go ou 8Go). De plus, comme vous avez pu le constater sur les liens que j'ai fourni, ou en fouillant dans le market, il semble que plusieurs pistes aient déjà été creusées (leaflet online, téléchargement de régions avant le voyage, routage offline à partir d'un GPX pré-chargé...) A mon avis, il reste à évaluer la piste de pack pré-packagés en raster et peut-être aussi en vecteur. Ensuite, il sera possible d'assembler toutes ces pistes pour construire un OSMand à la HTML5. Perso, je ne sais absolument pas comment évaluer la volumétrie d'une solution de stockage en tuile. Et c'est pour cela que je m'adresse à vous. Par exemple, les réponses aux questions suivantes peuvent aider à évaluer objectivement la pérénité d'une telle solution : - quel niveau de zoom permet de couvrir la France avec une occupation de 1Go ? - quelle zone est couverte au niveau 18 pour 1Go ? Si quelqu'un a des infos chiffrées sur le sujet, ça pourrait beaucoup aider. Merci d'avance. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO : pourquoi cette voie n'est pas rapprochée
Salut, Je ne comprends pas pourquoi cette voie n'est pas rapproché dans BANO : https://www.openstreetmap.org/way/317295760 Rue des Thermes Saint-Pierre, Village de la Cassière, Aydat 63026 Dans BANO : http://cadastre.openstreetmap.fr/fantoir/#insee=63026[1] « RUE DES THERMES ST PIERRE » qui est bien affichée Rue des Thermes Saint- Pierre dans la couche BANO. Une idée ? Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin [1] http://cadastre.openstreetmap.fr/fantoir/#insee=63026 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : pourquoi cette voie n'est pas rapprochée
Le 21/12/2014 23:41, Nicolas Dumoulin a écrit : Je ne comprends pas pourquoi cette voie n'est pas rapproché dans BANO : https://www.openstreetmap.org/way/317295760 Rue des Thermes Saint-Pierre, Village de la Cassière, Aydat 63026 Ça échoue alors que côté OSM il n'y a rien à dire (c'est dit :) ). En fait la cause est côté noms suffixés, cf. https://github.com/osm-fr/bano/issues/10 Ici, le nom de hameau La Cassière est ajouté à certains noms, dont la Rue du Four, et la Rue Rolland Brousse, qui touchent toutes 2 la Rue des Thermes Saint-Pierre. En jaune les zones dans lesquelles les rues croisées héritent d'un suffixe : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.690647lon=2.996386 Ce voisinage a contaminé cette rue, à laquelle je colle donc comme à ses voisines le suffixe La Cassière pour tenter de la retrouver dans les données OSM. Ça marche très bien pour ses voisines, mais pas pour elle. Au passage, on a 3 Rue du Four dans la commune, joli cas. Pour que les noms soient rapprochés ici, une possibilité est de tagguer explicitement la Rue des Thermes Saint-Pierre avec son code Fantoir. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : pourquoi cette voie n'est pas rapprochée
Bonsoir, Le lundi 22 décembre 2014 00:11:23 Vincent de Château-Thierry a écrit : Ici, le nom de hameau La Cassière est ajouté à certains noms, dont la Rue du Four, et la Rue Rolland Brousse, qui touchent toutes 2 la Rue des Thermes Saint-Pierre. En jaune les zones dans lesquelles les rues croisées héritent d'un suffixe : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.690647lon=2.9963 8 6 Ce voisinage a contaminé cette rue, à laquelle je colle donc comme à ses voisines le suffixe La Cassière pour tenter de la retrouver dans les données OSM. Ça marche très bien pour ses voisines, mais pas pour elle. Ha. Là je ne suis pas tout … je vois que tu avances bien sur la détection des villages, joli carte. J'ai plein de villages où les noms de rues sont suffixés avec le nom du village sur la couche BANO, mais pas rapprochés. Je rajoute donc le code Fantoir sur ces rues. Exemple ici, où je ne suis pas encore passé : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.74327/2.96708[1] Ce nom suffixé vient bien de Fantoir ? Je ne comprends pas quand tu dis l'ajouter pour mieux retrouver dans les données OSM. La couche BANO n'affiche pas la même chose que ce qui est utilisé par le script de rapprochement ? Au passage, on a 3 Rue du Four dans la commune, joli cas. Oulà, j'en ai plein dans le coin … Je me demande bien quel est le record :-) Pour que les noms soient rapprochés ici, une possibilité est de tagguer explicitement la Rue des Thermes Saint-Pierre avec son code Fantoir. Ok bien sûr, mais je trouvais étrange d'avoir besoin de le faire dans ce cas-ci. En fait, j'ai certainement pas compris ton explication ^^ … peut-être l'heure tardive. Merci Vincent -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin [1] http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.74327/2.96708 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Le problème est sur la rue Paul Vaillant Couturier, à Alfortville. J'ai relancé l'extraction à l'instant (avec l'overpass DE). Elle continue à m'intégrer des données supprimées depuis 20 jours. Voilà le zip contenant les données qui posent problème http://cadastre.openstreetmap.fr/data/094/Z0002-ALFORTVILLE-adresses-addrstreet_mix_en_facade_ou_isole.zip. Chaque nouvelle extraction écrase les précédentes ? Le 21 décembre 2014 22:02, Vincent de Château-Thierry osm.v...@free.fr a écrit : Le 21/12/2014 18:47, Vincent de Château-Thierry a écrit : Le 21/12/2014 17:06, Yoann Cornec a écrit : Là, elle a au moins 20 jours de retard. Est-ce que le script ne conserverai pas des données osm de précédentes exécutions en cache ? Mes modifs non prises en compte ont été faites après la première extraction des adresses de cette ville. Et tu as rejoué l'extraction récemment, mais sans bénéficier des mises à jour ? Je viens de regarder et on n'a pas de cache, du moins en théorie. Si tu peux m'indiquer la commune, je regarde ça ce soir. Possible que les soucis soient liés à l'overpass FR. J'ai basculé les traitements sur l'Overpass DE (overpass-api.de) et j'ai des résultats différents et cohérents. Si tu peux ré-essayer ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
la requete overpass ne recupere pas les relations type multipolygon avec le tag building= yes ET l'outer/inner n'a pas de tag building par exemple : http://www.openstreetmap.org/relation/974888 Le lundi 22 décembre 2014 à 02:13 +0100, Yoann Cornec a écrit : Le problème est sur la rue Paul Vaillant Couturier, à Alfortville. J'ai relancé l'extraction à l'instant (avec l'overpass DE). Elle continue à m'intégrer des données supprimées depuis 20 jours. Voilà le zip contenant les données qui posent problème. Chaque nouvelle extraction écrase les précédentes ? Le 21 décembre 2014 22:02, Vincent de Château-Thierry osm.v...@free.fr a écrit : Le 21/12/2014 18:47, Vincent de Château-Thierry a écrit : Le 21/12/2014 17:06, Yoann Cornec a écrit : Là, elle a au moins 20 jours de retard. Est-ce que le script ne conserverai pas des données osm de précédentes exécutions en cache ? Mes modifs non prises en compte ont été faites après la première extraction des adresses de cette ville. Et tu as rejoué l'extraction récemment, mais sans bénéficier des mises à jour ? Je viens de regarder et on n'a pas de cache, du moins en théorie. Si tu peux m'indiquer la commune, je regarde ça ce soir. Possible que les soucis soient liés à l'overpass FR. J'ai basculé les traitements sur l'Overpass DE (overpass-api.de) et j'ai des résultats différents et cohérents. Si tu peux ré-essayer ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Bonjour, Le 22/12/2014 07:15, didier2020 a écrit : la requete overpass ne recupere pas les relations type multipolygon avec le tag building= yes ET l'outer/inner n'a pas de tag building par exemple : http://www.openstreetmap.org/relation/974888 Le lundi 22 décembre 2014 à 02:13 +0100, Yoann Cornec a écrit : Le problème est sur la rue Paul Vaillant Couturier, à Alfortville. J'ai relancé l'extraction à l'instant (avec l'overpass DE). Elle continue à m'intégrer des données supprimées depuis 20 jours. Voilà le zip contenant les données qui posent problème. Chaque nouvelle extraction écrase les précédentes ? Didier pointe un manque dans les scripts, faudra y remédier. Le souci de Yoann est finalement bien lié à un phénomène de cache qui m'avait échappé et que je viens de désactiver. On voit donc plus de requêtes Overpass dans le process (certaines redondantes, qu'il faudrait factoriser) mais a priori on se cale sur les données actuelles de l'Overpass désormais, y compris pour les buildings. Yoann, si tu peux vérifier ? merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opendata... kinenveu ?
Bonjour, Je me suis déjà occupé des cimetières. Juste un nom changé, des améliorations de géométrie et l'ajout du crématorium. Romain Le 21 décembre 2014 16:49, Christian Quest cqu...@openstreetmap.fr a écrit : Deux jeux de données intéressants sur l'agglo de St Malo: - les arrêts de bus: https://www.data.gouv.fr/fr/datasets/emplacement-des-arrets-de-bus-du-reseau-transport-saint-malo-agglomeration-2/ - les casse bouteilles : https://www.data.gouv.fr/fr/datasets/points-dapport-volontaire-shp/ Mais aussi, sur la Ville de St Malo... - un parcours touristique: https://www.data.gouv.fr/fr/datasets/suivez-lhermine/ - les cimetières: https://www.data.gouv.fr/fr/datasets/cimetieres-malouins/ - les campings: https://www.data.gouv.fr/fr/datasets/campings/ - les monuments: https://www.data.gouv.fr/fr/datasets/monuments-historiques-classes-a-saint-malo/ - les stations service: https://www.data.gouv.fr/fr/datasets/emplacement-des-stations-service-a-saint-malo-1/ - les défibrillateurs: https://www.data.gouv.fr/fr/datasets/defibrillateurs-1/ - les postes de secours: https://www.data.gouv.fr/fr/datasets/postes-de-secours/ - les zones de mouillage: https://www.data.gouv.fr/fr/datasets/zones-de-mouillages/ - les bureaux de vote: https://www.data.gouv.fr/fr/datasets/emplacement-des-bureaux-de-vote/ Et aussi des POI du Comité Départemental de l'Aube (restaurant, hotellerie, patrimoine culturel, équipements sportifs, etc): https://www.data.gouv.fr/fr/datasets/etablissements-touristiques-de-laube-en-champagne/ -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] 松江まちあるきオープンデータソンのご案内
東です。 直前ですみません。 明日12/23(火・祝)am10時より島根県松江市でOSMマッピング＋uMapによる マッシュアップをやりますのでお近くにお住まいの方 よろしければお越しください。 松江まちあるきオープンデータソン http://www1.city.matsue.shimane.jp/shisei/toukei/toukei_jouhou/od.html ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] Totesport
Betfred took over Totesport a few years ago but there are still tags name=Totesport, name=totesport or operator=Totesport in Ashford, Birmingham(2), London (2), Manchester (2), Northampton, Oxford, Rotherham and Wakefield. -- Andrew ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21/12/2014 12:02, Andrew Hain wrote: Betfred took over Totesport a few years ago but there are still tags name=Totesport, name=totesport or operator=Totesport in Ashford, Birmingham(2), London (2), Manchester (2), Northampton, Oxford, Rotherham and Wakefield. I'd be tempted to add OSM notes for these containing a link to the problem node or way since http://www.openstreetmap.org/node/1117527074 hasn't been touched for four years; it's likely that other shops have changed hands too. Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
I'll add a note on the UK Retail section for bookies https://wiki.openstreetmap.org/wiki/UK_Retail_Chains#Betting_Shops. There are still one or two unharmonised tags for bookmakers: I moved a few amenity=bookmaker to shop=bookmaker the other day. At least one was one I created I'm pretty sure it was because I copied the tags from a pharmacy node which already had relevant address tags and then failed to change amenity to shop. This implies another possible tagging error mode which it's worth checking for. Some other tags which may be relevant to these shops: gambling (for available type of betting; not sure how one includes fixed-odds machines); and minage or min_age (although the former has much more usage, I find the case in favour of the latter is a good one). It's worth noting some other chains which have closed/taken over, as well - Notably there are lots of *Phones 4 U* shops (under a variety of names). All the one's I've physically checked have been closed and have a notice from the receivers. - *Co-operative Pharmacy*: the Co-op has sold these off to Bestway as part of trying to fix its finances after the combined Somerfield/Britannia takeover disasters. See BBC News http://www.bbc.co.uk/news/business-28361977 story Co-op http://www.thenews.coop/90565/news/business/co-operative-pharmacy-sale-finalised/ website. I imagine these will be re-branded at some point. I suspect that not all shops branded The co-operative pharmacy were in included in the deal, because, for instance Midshires Co-op still have their pharmacies. I'll check this with someone who is likely to know the details. Regards, Jerry On 21 December 2014 at 12:02, Andrew Hain andrewhain...@hotmail.co.uk wrote: Betfred took over Totesport a few years ago but there are still tags name=Totesport, name=totesport or operator=Totesport in Ashford, Birmingham(2), London (2), Manchester (2), Northampton, Oxford, Rotherham and Wakefield. -- Andrew ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21/12/14 13:56, SK53 wrote: There are still one or two unharmonised tags for bookmakers: I moved a few amenity=bookmaker to shop=bookmaker the other day. At least one was one I created I'm pretty sure it was because I copied the tags from a pharmacy node which already had relevant address tags and then failed to change amenity to shop. This implies another possible tagging error mode which it's worth checking for. In my view, they are not really bookmakers. For fixed odds, bookmaking requires no skill and for the horses, I imagine that all the bookmaking is done at head office. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21/12/2014 14:39, David Woolley wrote: In my view, they are not really bookmakers. For fixed odds, bookmaking requires no skill and for the horses, I imagine that all the bookmaking is done at head office. I'm not sure this detail is really relevant to us. Apply the Duck Test -- you go there to place a bet, so it's a bookmakers. We should be mapping for general use, and that may sometimes mean ignoring technical details of a particular industry if they have no effect on the public at large. J. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On Sun, 2014-12-21 at 14:39 +, David Woolley wrote: On 21/12/14 13:56, SK53 wrote: There are still one or two unharmonised tags for bookmakers: I moved a few amenity=bookmaker to shop=bookmaker the other day. At least one was one I created I'm pretty sure it was because I copied the tags from a pharmacy node which already had relevant address tags and then failed to change amenity to shop. This implies another possible tagging error mode which it's worth checking for. In my view, they are not really bookmakers. For fixed odds, bookmaking requires no skill and for the horses, I imagine that all the bookmaking is done at head office. +1 I think that is true of all of the big chains, they are better tagged as shop=betting and leave the tag shop=bookmakers for proper bookmakers where you can go in and speak to a skilled bookmaker. A point I made in the original thread on @tagging, and something I did survey at the time, the word bookmaker does not appear on Ladbrookes, Coral and the like. Phil ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21 Dec 2014 12:34, SomeoneElse li...@atownsend.org.uk wrote: On 21/12/2014 12:02, Andrew Hain wrote: I'd be tempted to add OSM notes for these containing a link to the problem node or way since http://www.openstreetmap.org/node/1117527074 hasn't been touched for four years; it's likely that other shops have changed hands too. Yes, I agree this is a textbook example of a case where adding notes is the best solution. There are relatively few of them, so it won't flood the notes system, and some of them will have closed in the meanwhile or not been taken over in the first time, so there is no way to solve this remotely. Feel free to go ahead. I can address the Birmingham ones when I'm around. -- Matthijs ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21 Dec 2014 13:57, SK53 sk53@gmail.com wrote: Notably there are lots of Phones 4 U shops (under a variety of names). All the one's I've physically checked have been closed and have a notice from the receivers. I spotted a few that have been taken over by Vodafone and EE. I think all of them need to be checked indivdually. -- Matthijs ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
On 21 Dec 2014 14:40, David Woolley for...@david-woolley.me.uk wrote: In my view, they are not really bookmakers. For fixed odds, bookmaking requires no skill and for the horses, I imagine that all the bookmaking is done at head office. We decided on shop=bookmaker some time ago: http://wiki.openstreetmap.org/wiki/Proposed_features/Gambling#Voting I don't feel strongly either way, but I think it's best to stick with the decision taken by the community. Note also that the shop=betting tag is ambiguous: it was used for bookmakers, adult gaming centres and lottery shops (the latter being popular in Spain). They are all quite different, so I guess it's good to get rid of the ambiguity. -- Matthijs ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Totesport
Ah, but then you move into the realms that we should move everything to shop=betting :-) I was only thinking about this in the context of anyone wanting to use the gambling https://wiki.openstreetmap.org/wiki/Key:gamblingtag. See taginfo for current values https://taginfo.openstreetmap.org/keys/?key=gambling#values. Mind you I'm not sure how much control individual shop managers have over odds in the chain bookies either. Jerry PS. I've entered a bookies once in my life. And that very recently to purloin a pencil whilst out surveying, because I'd mislaid mine. So no expert. On 21 December 2014 at 14:39, David Woolley for...@david-woolley.me.uk wrote: On 21/12/14 13:56, SK53 wrote: There are still one or two unharmonised tags for bookmakers: I moved a few amenity=bookmaker to shop=bookmaker the other day. At least one was one I created I'm pretty sure it was because I copied the tags from a pharmacy node which already had relevant address tags and then failed to change amenity to shop. This implies another possible tagging error mode which it's worth checking for. In my view, they are not really bookmakers. For fixed odds, bookmaking requires no skill and for the horses, I imagine that all the bookmaking is done at head office. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Post-Christmas Midlands OSM Meet-up
Thanks to everyone who has participated in the Doodle poll. I plan to leave it open until Tuesday evening (23rd Dec), and will choose the date to enable as many as possible to come along. (Check Doodle to see the current situation). I will then add it to the OSM Wiki. This is just to advise that the likely location is Hanbury / Draycott-in-the-Clay, West of Burton-on-Trent. This gives a chance to map some completely unmapped footpaths and to visit the edge of the Fauld crater https://en.wikipedia.org/wiki/RAF_Fauld_explosion (which is somewhere that several of us have had on 'to visit' lists). There seems to be a reasonable choice of pubs in the immediate area too. Cheers, Jerry ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Rail westerly
stevea wrote: Alexander Jones wrote: * I'm in the process of retracing most of the current and abandoned lines in the San Joaquin Valley south of Stockton. Especially on the BNSF line, don't waste your time. I'm not sure why you think this is waste of time, but I appreciate the heads-up that you are working here! I was trying to say, Let's not duplicate work. It's not a waste, but I wanted to let you know I was going to be remapping that segment anyway. * I generally use 7 tags: railway=rail, operator=, old_railway_operator=, name=, usage=, electrified=, and gauge=. Yes, I'll use owner= if known, and it is name= which displays in ORM as the name of the line. Many lines had name= as the service run upon them (like Caltrain instead of Union Pacific), and I have corrected this where I know it was wrong in OSM. But I haven't corrected all of these, just the ones I know. And now I think I'll have to go back and correct name=Union Pacific as the name of Union Pacific's subdivision for the line that Caltrain is run upon: Caltrain itself should be a relation. And so on. If Wikipedia is to be believed, Caltrain owns the track between San Francisco and Tamien Station, and the UP owns the track south to Gilroy. * I still use old-fashioned (according to OpenRailwayMap) route=railway relations for the tracks. I don't think the relations are rendered, but I'm not completely sure. But I keep the IDs in the org-mode files I use to manage my work, so I could always switch the tag out if needed. I didn't quite follow that (and I agree: it appears route relations are not rendered in ORM). Sorry. I was noting the software I use for managing my rail remap projects. Charlotte wrote: Thanks for the tip about openrailwaymap.org. I have aligned many railroads in Arizona and added many others. But I distrust the naming there, so I just have left that alone. Also, I don't know how to do relations, so, if you finish California, feel free to make relations in Arizona. Relations can be a challenge for some OSM contributors. While it is technically possible to edit relations with either iD or Potlatch 2, I don't recommend it, as the GUI is klunky, confusing and error-prone. JOSM is a much better editor to edit relations in OSM (imo), and while there is a learning curve that takes practice to get the hang of it, it is relatively short and is only a small mountain to conquer. You can do it! Learning JOSM is well worth it if you're going to do any complex mapping. Great to see this enthusiasm and good communication. SteveA California Alexander ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail westerly
On 2014-12-20 18:59, Natfoot wrote: Steve, If you are finding PCIX those are the call letters for the railroad that is the owner, they may also be the operator. Now here is the tricky bit, I will use the example of a local short line railroad. This railroad the property is owned by the county and the port; one railroad (GNPX) has the operating rights who then contracts with a second company that is a railroad (BDTL) yet the line in which they are running is known as another railroad (ESFR). If any of you can sort this out into the proper categories I think it will help a few many people. I'm also trying to get my head around a slightly simpler case. The Cincinnati Southern Railway [1] is owned by the City of Cincinnati and leased out to the Cincinnati, New Orleans Texas Pacific Railway (CNTP), a subsidiary of Norfolk Southern (NS). The relations -- one for each subdivision [2][3][4] -- don't indicate their ownership by the city anywhere. (`name` contains CNOTP and `operator=NS`.) It sounds like I would just need to add `owner=City of Cincinnati` to the relations. Would that be correct, or would the lessee go in `owner`? [1] https://en.wikipedia.org/wiki/Cincinnati_Southern_Railway [2] http://osm.org/relation/2250839 [3] http://osm.org/relation/2250840 [4] http://osm.org/relation/1441409 -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Rail westerly
Alexander writes: I was trying to say, Let's not duplicate work. It's not a waste, but I wanted to let you know I was going to be remapping that segment anyway. Thanks. Good to be working with you! (And other OSM railfans in the USA). I'll stay away from / not edit this segment, but I'm beginning to better utilize your tagging inclinations as they seem to be correct OSM tagging and render better with ORM. ORM's tagging guidelines (on OSM's wiki) are clear that there are three distinct components in its section Railway Lines: Railway Lines are mapped with relations, and split between three categories that should not be mixed up: infrastructure, railway route, and train route. I had to re-read this part of this very comprehensive wiki a few times to get the hang of how to do these three relation styles (well, as a first cut in the USA, way tags for infrastructure, possibly a Railway Line relation -- some overlap here -- for physical infrastructure as well, and then two relations for Railway Route and Train Route.) This tagging scheme is extremely rich: it is well thought out and seems to work very well for Germany where it was developed (together with the ORM renderer), though there are provisions to make country-specific tagging schemes, too. Excellent! While I don't think we need to do this (yet?) in the USA, good that we can. So, a simplified first step is to tag ways (railway=rail, railway=tram, railway=light_rail, railway=subway...) with physical infrastructure tags (usage=main if true, service=siding if true...) and name=Subdivision Name (where known), possible with owner= and/or operator= tags as well. The richness of potential tagging includes signalling, interlocking, electrification, crossings... but while we should strive to enter these where known, they seem less important than this simplified first step. A complete first step would be to then get infrastructure relations complete. The second and third steps of Railway Route and Train Route (relations) can come later, but if there are routes known, they can proceed directly to relations -- though the physical infrastructure (whether as ways or relations) really must come first to do that. Clear as mud, right? (I think OSM finally has Caltrain about correct in California's Bay Area, but only perhaps these first two steps or so). The upshot/short version? I strongly believe this should be better worked on here in the USA to our rail, and that we have a LOT of work (research, surveys, editing...) to do to achieve this. Excellent project we have mapping our beautiful home planet, here: Go, OSM! SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Retail Example using OSM
Michaels craft stores http://www.michaels.com/store-locator ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-cl] Listado de correciones
Hola, que bueno que se hizo una planilla para esto. Añadí una columna para comentarios porque vi que algunos ponían comentarios en la columna de abreviaturas y yo necesité hacer comentarios en un par de casos que añadí. En total añadí cerca de 50 casos. Esta vez me di cuenta de que existen muchos problemas con establecimientos educaciones que tienen muchas abreviaturas e incluso nombres cortados (Huechura en vez de Huechuraba, Prad en vez de Prado, etc.). Quizás sería bueno ver eso también, pero revisando mejor la base de datos que se importó o el resultado de esa base de datos, que no sé de dónde vendrá el problema, si de antes o producto del proceso de importación. Saludos 2014-12-18 11:21 GMT-03:00 Álvaro Monares G. amona...@dcc.uchile.cl: Estimados, dado el recibimiento que ha tenido el cambio de nombres en Chile es que he dejado disponible para editar los cambios que se han hecho, para recibir comentarios y/o complementar https://docs.google.com/spreadsheets/d/1zEBDIfCX3SMEwOiRa9wVoBdoNWk4N Srt4Ksth0WxXm0/edit?usp=sharing Estoy pensando en que la próxima etapa es hacer una interfaz web, que ofrezca cambiar nombres, con cosas que no son tan fáciles de hacer masivamente y que necesitan del ojo humano, como calles con algún espacio y un punto por ejemplo: Pasaje .Prieto Dr .F. Lavalle Cruce.Viviana Sur Calles todas mayúsculas o minúsculas. O revisar las calles que contegan apellidos de personas importantes como Cerda y ver que este bien escrito Pedro Aguirre Cerda y otros que surgan Saludos Álvaro Monares G. ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
Re: [Talk-cl] Listado de correciones
Por ahora los cambios los realizé sólo en la calles, o más específico en la primitiva way. No he tocado otro tipo aún. Eso de la abreviaciones, se podrían resolver mediante un formulario, que vaya ofreciendo por ejemplo todas las escuelas, y digan si está bien o se debe modificar e indicar la modificación. Luego si alguien dijo que se debe modificar entonces que pase por otra persona para validar el cambio y luego enviarlo. Esto permitiría por ejemplo corregir aquellas calles que conservan algún punto en su escritura. Saludos y felices fiestas Álvaro Monares G. El 21-12-2014 a las 17:25, Felipe Raimann escribió: Hola, que bueno que se hizo una planilla para esto. Añadí una columna para comentarios porque vi que algunos ponían comentarios en la columna de abreviaturas y yo necesité hacer comentarios en un par de casos que añadí. En total añadí cerca de 50 casos. Esta vez me di cuenta de que existen muchos problemas con establecimientos educaciones que tienen muchas abreviaturas e incluso nombres cortados (Huechura en vez de Huechuraba, Prad en vez de Prado, etc.). Quizás sería bueno ver eso también, pero revisando mejor la base de datos que se importó o el resultado de esa base de datos, que no sé de dónde vendrá el problema, si de antes o producto del proceso de importación. Saludos 2014-12-18 11:21 GMT-03:00 Álvaro Monares G. amona...@dcc.uchile.cl mailto:amona...@dcc.uchile.cl: Estimados, dado el recibimiento que ha tenido el cambio de nombres en Chile es que he dejado disponible para editar los cambios que se han hecho, para recibir comentarios y/o complementar https://docs.google.com/spreadsheets/d/1zEBDIfCX3SMEwOiRa9wVoBdoNWk4NSrt4Ksth0WxXm0/edit?usp=sharing Estoy pensando en que la próxima etapa es hacer una interfaz web, que ofrezca cambiar nombres, con cosas que no son tan fáciles de hacer masivamente y que necesitan del ojo humano, como calles con algún espacio y un punto por ejemplo: Pasaje .Prieto Dr .F. Lavalle Cruce.Viviana Sur Calles todas mayúsculas o minúsculas. O revisar las calles que contegan apellidos de personas importantes como Cerda y ver que este bien escrito Pedro Aguirre Cerda y otros que surgan Saludos Álvaro Monares G. ___ Talk-cl mailing list Talk-cl@openstreetmap.org mailto:Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
Re: [talk-latam] Mapazonia: Rio Acre forma una frontera
ContourmMerge! no recordaba el nombre, gracias :) On 20/12/14 20:17, Jo wrote: Si instalan el ContourMerge plugin es facil de pegar la frontera al río. No olvidar de deseleccionar los puntos con esas cruces amarillos, antes de intentar otro tramo. Polyglot 2014-12-20 23:31 GMT+01:00 Wille wi...@wille.blog.br mailto:wi...@wille.blog.br: Buena sugestión, Alex. Ya he actualizado el Tasking Manager. On 20-12-2014 19:45, Alex Barth wrote: Hola todo/as - (Super emocionado por la iniciativa de #mapazonia) Veo que despegamos la frontera del Rio Acre que no es correcto: http://cl.ly/image/2Q2c2S1e2W2l Quien puede agregar mejores instrucciones en el tasking manager? Algo así: === Parte del Río Acre forma una frontera entre Bolivia y Brazil http://es.wikipedia.org/wiki/Fronteras_de_Bolivia#L.C3.ADmites_de_Bolivia-Brasil y entre Perú y Brazil: Por el río Acre, aguas abajo, hasta la boca del riachuelo Yaverija, donde empieza la frontera con Bolivia, cerca al poblado de Iñapari. http://es.wikipedia.org/wiki/Fronteras_del_Per%C3%BA Los ways de la frontera deben ser pegados con el centro del río, así: http://cl.ly/image/0a2a1O2V1m0N Pero no así: http://cl.ly/image/2Q2c2S1e2W2l === Alex (Marco Antonio, copio a tí por que levantaste este tema en el Mapazonia hilo) ___ talk-latam mailing list talk-latam@openstreetmap.org mailto:talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ talk-latam mailing list talk-latam@openstreetmap.org mailto:talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam
