[OSM-talk] weekly 230 in English is online
The weekly round-up of OSM news, issue # 230, is now available online in English, giving as always a summary of all things happening in the openstreetmap world: http://www.weeklyosm.eu Enjoy! -- ## Manfred ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] hierarchical or flat multipolygons?
Hi. I'm editing the Hudson River all as one entity, from its beginning in the Adirondacks to its end at NYC. Along the way, there are some islands that need to be excluded, so it's not just riverbank, riverbank, riverank. It's riverbank, multipolygon(riverbank, island, island), riverbank. In theory at least, I could make the whole riverbank into one multipolygon, with a bunch of outers (about 50) and inners (about 200). Would that create a problem for other editors? To load the whole thing, you would have to load a LOT of nodes. Or, conversely, should I keep it as about 20 plain ways and 30 multipolygons? But what kind of a relation do I make for the entire riverbank? It was type=collection, but the wiki barfs all over that. I tried making it a multipolygon of multipolygons, but JOSM barfs up on that (Non-Way in multipolygon). Is there even a way to tag this properly? For now, I'm keeping it as type=collection just to upload it for safekeeping. Should this Hudson Riverbank relation be flat or hierarchical? -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] hierarchical or flat multipolygons?
On 23 Dec 2014 04:19:49 -, Russ Nelson wrote: Hi. I'm editing the Hudson River all as one entity, from its beginning in the Adirondacks to its end at NYC. Along the way, there are some islands that need to be excluded, so it's not just riverbank, riverbank, riverank. It's riverbank, multipolygon(riverbank, island, island), riverbank. In theory at least, I could make the whole riverbank into one multipolygon, with a bunch of outers (about 50) and inners (about 200). Would that create a problem for other editors? To load the whole thing, you would have to load a LOT of nodes. That would not only be a problem for other editors but create a relation which is hard to handle, easily to break and sooner or later /will/ be broken more or less accidental by someone. See also http://wiki.openstreetmap.org/wiki/Relation#Size Or, conversely, should I keep it as about 20 plain ways and 30 multipolygons? But what kind of a relation do I make for the entire riverbank? […] Should this Hudson Riverbank relation be flat or hierarchical? In the early beginnings I also used to put all stuff for one river in one relation – only to rip it apart later after gathering enough knowledge. Though there is a relation type waterway¹ I think it and all the work some people put in it superfluous – even more with the not really documented watershed relation² which mappers want to show a whole watershed… See also: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories When you have a highway split into several parts because of varying surface, maxspeed, sidewalk values etc you usually don't create a relation with the name of the highway. The same logic you can apply for rivers and watersheds. When all the parts of the riverbanks have riverbank=* and name=* on them it is an easy task to query for them, e.g. with http://overpass-turbo.eu Regarding watershed relations (although you didn't ask for them): Martin Kompf managed to make a map of all waterways of Central Europe showing the watersheds – without having relations everywhere: http://www.kompf.de/gps/rivermap.html tl;dr regarding your question Should this Hudson Riverbank relation be flat or hierarchical? If you still think you need a relation for all Hudson River, don't make it a flat one – this would be the worst choice. hth Thomas ¹ http://wiki.openstreetmap.org/wiki/Types_of_relation ² http://wiki.openstreetmap.org/wiki/Relation:watershed ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Taglocator
Ik maakte er al eerder melding van, maar inmiddels is er al aardig wat veranderd en bijgekomen in de taglocator. Er zijn nu twee versies: De basisversie: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/ De versie met namen: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/tagnames.html Vooral handig om te zien wat er in je omgeving nog niet is getagd! Zoom in op je woonplaats en kies bv. shop uit het menu. Kies de winkels die je wilt zien (waarvan je weet dat ze er zijn) en wacht even af om te zien of ze ook op OSM tevoorschijn komen. Dat valt vaak nog behoorlijk tegen. Want er zijn nog veel plaatsen waar wel alle wegen tot in detail zijn terug te vinden, maar waar is de bakker? Waar de drogist? Waar de benzinepomp? Reacties graag weer hier. Maar lees ook de vele commentaren op het forum: http://forum.openstreetmap.org/viewtopic.php?id=28807 Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Taglocator
Cool! 2014-12-22 15:47 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Ik maakte er al eerder melding van, maar inmiddels is er al aardig wat veranderd en bijgekomen in de taglocator. Er zijn nu twee versies: De basisversie: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/ De versie met namen: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/tagnames.html Vooral handig om te zien wat er in je omgeving nog niet is getagd! Zoom in op je woonplaats en kies bv. shop uit het menu. Kies de winkels die je wilt zien (waarvan je weet dat ze er zijn) en wacht even af om te zien of ze ook op OSM tevoorschijn komen. Dat valt vaak nog behoorlijk tegen. Want er zijn nog veel plaatsen waar wel alle wegen tot in detail zijn terug te vinden, maar waar is de bakker? Waar de drogist? Waar de benzinepomp? Reacties graag weer hier. Maar lees ook de vele commentaren op het forum: http://forum.openstreetmap.org/viewtopic.php?id=28807 Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl -- Henk Nouws ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Taglocator
Dat ziet er goed uit Marc! Wat ik nog mis zijn klikbare links. Met name natuurlijk voor de website en wikipedia tags. Dit zou bereikt kunnen worden door een xml bestand te downloaden van overpass in plaats van een html bestand. Met behulp van een xslt scriptje kan van het xml bestand weer een html tekst gemaakt worden, maar dan met links voor de tags waar dat van toepassing is. Ik heb een voorbeeld xslt scriptje geschreven. Dit scriptje maakt links voor de volgende tags: wikipedia, website, url, twitter, mdb_id en dhm_id Gertjan ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=utf-8 lang=en/ titleOSM3S Response/title /head body h2POIs/h2 xsl:apply-templates/ /body /html /xsl:template xsl:template match =osm/node | osm/way | osm/relation p !-- De naam van het object indien aanwezig -- xsl:if test=tag[@k='name'] strongxsl:value-of select=tag[@k='name']/@v/br//strongxsl:text#10;/xsl:text /xsl:if !-- De link naar het object op openstreetmap.org -- a target=_blankxsl:attribute name=hrefhttp://www.openstreetmap.org/browse/xsl:value-of select=name()//xsl:value-of select=@id//xsl:attributexsl:value-of select=name()/xsl:text /xsl:textxsl:value-of select=@id//abr/xsl:text#10;/xsl:text xsl:apply-templates select=tag/ /p /xsl:template !-- Behandeling van gewone tags -- xsl:template match =tag xsl:value-of select=@k/: xsl:value-of select=@v/br/xsl:text#10;/xsl:text /xsl:template !-- wikipedia -- xsl:template match =tag[@k='wikipedia'] xsl:variable name=wikixsl:value-of select=@v//xsl:variable Wikipedia: a target=_newxsl:attribute name=hrefhttp://xsl:value-of select=substring($wiki, 1, 2)/.wikipedia.org/wiki/xsl:value-of select=substring($wiki, 4)/ /xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- website -- xsl:template match =tag[@k='website'] Website: a target=_newxsl:attribute name=hrefxsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- twitter -- xsl:template match =tag[@k='twitter' or @k='contact:twitter'] Twitter: a target=_newxsl:attribute name=hrefhttp://www.twitter.com/xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- url -- xsl:template match =tag[@k='url'] URL: a target=_newxsl:attribute name=hrefxsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- molendatabase -- xsl:template match =tag[@k='mdb_id'] Molendatabase: a target=_newxsl:attribute name=hrefhttp://www.molendatabase.nl/nederland/molen.php?nummer=xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template !-- molens.nl -- xsl:template match =tag[@k='dhm_id'] De hollandsche molen: a target=_newxsl:attribute name=hrefhttp://www.molens.nl/site/dbase/molen.php?mid=xsl:value-of select=@v//xsl:attributexsl:value-of select=@v//abr/xsl:text#10;/xsl:text /xsl:template xsl:template match =text()/ /xsl:stylesheet On Mon, 2014-12-22 at 15:47 +0100, Marc Zoutendijk wrote: Ik maakte er al eerder melding van, maar inmiddels is er al aardig wat veranderd en bijgekomen in de taglocator. Er zijn nu twee versies: De basisversie: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/ De versie met namen: http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/tagnames.html Vooral handig om te zien wat er in je omgeving nog niet is getagd! Zoom in op je woonplaats en kies bv. shop uit het menu. Kies de winkels die je wilt zien (waarvan je weet dat ze er zijn) en wacht even af om te zien of ze ook op OSM tevoorschijn komen. Dat valt vaak nog behoorlijk tegen. Want er zijn nog veel plaatsen waar wel alle wegen tot in detail zijn terug te vinden, maar waar is de bakker? Waar de drogist? Waar de benzinepomp? Reacties graag weer hier. Maar lees ook de vele commentaren op het forum: http://forum.openstreetmap.org/viewtopic.php?id=28807 Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] 663 Bäume mit identischer Internetaddresse..
Am 21. Dezember 2014 um 17:01 schrieb Volker Schmidt vosc...@gmail.com: Ausserdem haben di Baeume ein denotation=cluster, was ich nicht verstehe, und fuer das ich keine vernuenftige wiki Seite finde. Diesen tag hat vor Jahren ein User eingeführt, nachdem er sich darüber geärgert hatte, dass nicht nur besondere Bäume sondern Allerweltsbäume mit natural=tree getaggt wurden. Der cluster-tag ist dabei lediglich ein automatisch erzeugter (und getaggter) Hinweis, dass in der Nähe des Baums noch weitere Bäume gemappt sind. Alternative etablierte Werte für denotation, die auf eine manuelle Überprüfung hindeuten, sind urban (städtischer Baum, z.B. im Park, keine Alleen), avenue (Allee) und natural_monument. Ausserdem noch landmark. Der Rest kommt unter 1000x vor (park wäre ggf. noch zu nennen, alley ist vermutlich ein typo und sollte avenue sein: http://taginfo.osm.org/keys/denotation#values ). Zusammengefasst bedeutet cluster, dass sich das noch niemand genauer angesehen hat im Hinblick auf die Typologie des Baums. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, folgende Gedanken: ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam? -ggf. einen Bordstein, -grob den gleichen Verlauf, -den gleichen Straßennamen, -die gleiche Beleuchtung Was ist unterschiedlich? -Der Verlauf im Detail -Fahrbahnbelag, -Nutzungsvorgaben (access) -Einbahnstraßenregelungen (Fast alle straßenbegleitenden innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege hingegen nicht.) -Spuraufteilung -Abbiegebeschränkungen Ich halte das Anbringen von Fuß- und Radweginformation an der Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in die Details geht sollte die Wege als einzelne Linienzüge erfasst werden. Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht. Viele Grüße Hadhuey Am 20.12.2014 um 03:03 schrieb 715371: Am 09.12.2014 um 13:17 schrieb Hubert: Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt logisch wäre. Mir fehlt hier noch die Diskussion weshalb man nun etwas separat erfassen sollte bzw. nicht. Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine abgesenkt sind. Oder das zumindest so vorkommt, so dass man die straßenbegleitenden Wege ohne Komplikationen befahren kann. Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man (in D-Land) eher als default annehmen sollte, dass alles Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung oder Einmündung alles machen können. Wenn das nicht der Fall sein sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine Relation einführen, die der restriction-Relation ähnelt. ___ 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] cycleway=track bei Bordstein Trennung
Am 21.12.2014 um 15:20 schrieb Hubert: 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. +1 Die Info ruft dann zwar nicht mehr Fehler hervor, wenn sie fehlt, aber ist natürlich immer noch interessant. bicycle=mandatory/obligatorry wäre in dem Kontext zumindest ein Tagging über das ich noch nicht nachgedacht habe. Problem ist vielleicht, dass es alleine am Radweg keine access-Bedeutung hat/haben könnte. 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. Und dazwischen sind auch alle Meinungen möglich. Hast du die Hauptprobleme, die seitdem diskutiert wurden irgendwo dokumentiert? Oder weißt du, ob es so etwas gibt? Wenn sich diese Diskussion immer wieder wiederholt, ist das auch nicht sehr produktiv. Eure/Unsere Meinungen und Vorschläge würde ich sonst gerne einmal zusammenfassen. 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? Graben, Rasenfläche - Trennung Bordstein, Geländer ist diskutabel, weil es eher auf die Situation ankommt. 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 des separaten/doppelten mappens entsteht bei Radwegen ja maximl bei cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die Straße gemappt. Ich musste jetzt auch lange nachdenken, was ich damit sagen wollte, entschuldige! Ich habe in diesem Zusammenhang beim Rendern irgendein weiteres Problem vermutet. Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht ein
Re: [Talk-it] Tag per CAF?
io avevo usato office=tax -- View this message in context: http://gis.19327.n5.nabble.com/Tag-per-CAF-tp5826482p5827966.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Sardegna Fase 2 : Indirizzi
2014-12-22 0:13 GMT+01:00 Luca Meloni lmelonim...@yahoo.it: più di uno a testa non c'era la certezza di come inserirli (ci sono comunque, ma non so se possano essere esportati decentemente). Se agid/poste italiane non escecon la mappa dei CAP (e mi pare che non stiano minimamente rispettando i patti), mi piacerebbe uscire con un raggruppamento dei cap presi da osm. raggruppati per poligono di CAP omogeneo. qui una query per estrarli su cagliari http://overpass-turbo.eu/s/6D9 -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag per CAF?
2014-12-22 9:10 GMT+01:00 dvdzero dvdz...@gmail.com: io avevo usato office=tax se decidiamo di usare office=accountant o office=tax sarebbe comunque bene accordarsi di aggiungerne un altro tag che dice chiaramente che si tratta di un CAF. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tag rosticceria
2014-12-19 18:36 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org: Francesca, non dobbiamo trascurare la ragione sociale presente sullo scontrino fiscale. si, va messo in operator. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag per CAF?
Concordo con Martin. Decidiamo un tag appropiato? Il giorno 22 dicembre 2014 10:04, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2014-12-22 9:10 GMT+01:00 dvdzero dvdz...@gmail.com: io avevo usato office=tax se decidiamo di usare office=accountant o office=tax sarebbe comunque bene accordarsi di aggiungerne un altro tag che dice chiaramente che si tratta di un CAF. ciao, Martin ___ 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] Tag per CAF?
22.12.2014 - 20:22 - John Doe: Concordo con Martin. Decidiamo un tag appropiato? Cosa ne dite di questo: office=accountant accountant=it:caf Ciao Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] DB Topografico Lombardia
nel mentre vorrei ricordarvi questo:
http://wiki.openstreetmap.org/wiki/Lombardia/Import_Database_Topografico_Lodi
Ruggero
Il 28 novembre 2014 14:20, sabas88 saba...@gmail.com ha scritto:
Ciao,
ho scoperto che è stato reso disponibile il db topografico della Lombardia
(prima mi risultava ci fosse solo Lodi), ma non è su dati.lombardia.it
Si raggiunge da Download Dati qua
http://www.cartografia.regione.lombardia.it/geoportale/ptk
Ho scaricato un paio di temi per Pero, e noto che ci sono edificato (con le
altezze, quindi dati tridimensionali), civici e toponomastica.
Si organizza un import?
La licenza è IODL 2.0, quindi compatibile. (scheda metadato
http://www.cartografia.regione.lombardia.it/geoportale/DiscoveryServlet?command=viewdetailsuuid={4D4F58F6-6A38-8F7E-2B82-3E49FC5D1ED4}
)
Io gradirei che si incominciasse dai dintorni dell'Expo, non si sa mai...
Ciao,
Stefano
___
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] ZTL e zona pedonale
Anche se è passato un po' di tempo vorrei tornare sull'argomento per cercare di capire quale sia il miglior modo per mappare una ZTL. Dal discorso fatto sin'ora, anche in altri thread, capisco che è possibile inserire tutte le limitazioni per ogni singola via interessata, come indicato da Martin: 2014-11-18 13:22 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: Metterei un generico motor_vehicle=private invece della chiave access. Poi eccezioni generici per i veicoli che valgono a prescindere della data/orario: psv=yes emergency=yes disabled=yes se lo vuoi mappare precisamente, dovresti poi usare i tags del tipo conditional per ogni classe/categoria per esempio motor_vehicle:conditional=delivery @ (Mo-Fr 08:00-10:00,15:00-16:00) per consegne lunedì - venerdì 8-10 e 15-16. Fin qui va bene, ma dove mettiamo i tags? Per far funzionare gli attuali router (avanzati, perché quelli semplici non credo che capiscono i conditional restrictions) dovresti (credo) mettere tutti quei tags a tutte le strade dentro la ZTL. ;-) Il minimo sono quelli che servono d'accesso. Metterei i tags _anche_ alla relazione della ZTL Ma oltre alla relazione type=LEZ (che non mi sembra molto appropriata) esistono altre relazioni per individuare una ZTL? Ossia che tipo di relazione sarebbe meglio utilizzare? Secondo me potrebbe essere utile avere un'unica relazione nella quale inserire tutte le strade che rientrano nella ZTL (non solo quelle che la contornano come visto fare a Roma) insieme ai varchi, magari con appositi role. Ho sentito parlare di relazioni type=enforcement, enforcement=access, ma mi pare che servano solo per mappare il singolo rilevatore per l'accesso alla ZTL. Anche il boundary=limited_traffic_zone, per definire il perimetro della zona, non mi sembra una soluzione molto soddisfacente. Insomma sarebbe bello avere un metodo funzionante per questo tipo di restrizioni. Voi che ne pensate? Grazie Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA - Comunicado de prensa N° 202
*Comunicado de prensa N° 202* *Bogotá 22 de diciembre de 2014* *EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA* *El evento sucedió en la madrugada del domingo, como consecuencia de las lluvias que se presentaron al sur del Departamento e involucró a los ríos San Bingo y Mazamorras* *22 de diciembre de 2014. *Desde el momento de la emergencia sucedida a raíz de las lluvias presentadas en la tarde del sábado y la madrugada del domingo, el Sistema Nacional de Gestión del Riesgo de Desastres se activó para brindar atención a la emergencia que dejó a su paso 3 personas fallecidas, 50 casas afectadas y destrucción de 6 puentes vehiculares y 4 peatonales en los municipios de Mercaderes y Bolívar. Tras la coordinación del nivel Municipal, Departamental y Nacional y bajo el conocimiento del Presidente de la República, un equipo técnico de la Unidad Nacional para la Gestión del Riesgo de Desastres, UNGRD, se desplazó a la zona para la determinación de daños y análisis de necesidades, para adelantar las acciones de atención, resumidas así: - Activación del Sistema Nacional de Gestión del Riesgo - Acciones de Búsqueda y Rescate - Movilización del Batallón de Ingenieros del Ejército Nacional - Disposición de Banco de Maquinaria del Departamento - Evaluación de daños para la recuperación de puntos críticos - Coordinación del nivel Municipal, Departamental y Nacional En el día de mañana, el Director de la UNGRD, Carlos Iván Márquez Pérez, estará haciendo un recorrido de verificación por los municipios de Mercaderes y Bolívar y la entrega de ayudas de Asistencia Humanitaria de Emergencia, relativas a kits de mercado y materiales para la recuperación de viviendas. Seguiremos informando. *Diana Londoño* – Jefe Oficina Asesora de Comunicaciones 3124483908 diana.lond...@gestiondelriesgo.gov.co *Oficina Asesora de Comunicaciones* Unidad Nacional para la Gestión del Riesgo de Desastres *Teléfono:* 5529696 Ext.500 Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a prensa+unsubscr...@dgr.gov.co. ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA - Comunicado de prensa N° 202
Hola maperos El dia de mañana estará en la zona Carlos Andres barrera (Puentero) quien nos solicita que colaboremos en el mapeo de la zona. Carlos pertenece a Unidad Nacional para la Gestión del Riesgo de Desastres y fue precisamente quien hizo famoso el mapa de OSM en la atención del terremoto en Haiti. Les parece si organizamos un task y nos ponemos en la tarea? salu2 Humano 2014-12-22 10:37 GMT-05:00 Gestión del Riesgo de Desastres Ungrd comunicacio...@gestiondelriesgo.gov.co: *Comunicado de prensa N° 202* *Bogotá 22 de diciembre de 2014* *EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA* *El evento sucedió en la madrugada del domingo, como consecuencia de las lluvias que se presentaron al sur del Departamento e involucró a los ríos San Bingo y Mazamorras* *22 de diciembre de 2014. *Desde el momento de la emergencia sucedida a raíz de las lluvias presentadas en la tarde del sábado y la madrugada del domingo, el Sistema Nacional de Gestión del Riesgo de Desastres se activó para brindar atención a la emergencia que dejó a su paso 3 personas fallecidas, 50 casas afectadas y destrucción de 6 puentes vehiculares y 4 peatonales en los municipios de Mercaderes y Bolívar. Tras la coordinación del nivel Municipal, Departamental y Nacional y bajo el conocimiento del Presidente de la República, un equipo técnico de la Unidad Nacional para la Gestión del Riesgo de Desastres, UNGRD, se desplazó a la zona para la determinación de daños y análisis de necesidades, para adelantar las acciones de atención, resumidas así: - Activación del Sistema Nacional de Gestión del Riesgo - Acciones de Búsqueda y Rescate - Movilización del Batallón de Ingenieros del Ejército Nacional - Disposición de Banco de Maquinaria del Departamento - Evaluación de daños para la recuperación de puntos críticos - Coordinación del nivel Municipal, Departamental y Nacional En el día de mañana, el Director de la UNGRD, Carlos Iván Márquez Pérez, estará haciendo un recorrido de verificación por los municipios de Mercaderes y Bolívar y la entrega de ayudas de Asistencia Humanitaria de Emergencia, relativas a kits de mercado y materiales para la recuperación de viviendas. Seguiremos informando. *Diana Londoño* – Jefe Oficina Asesora de Comunicaciones 3124483908 diana.lond...@gestiondelriesgo.gov.co *Oficina Asesora de Comunicaciones* Unidad Nacional para la Gestión del Riesgo de Desastres *Teléfono:* 5529696 Ext.500 Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a prensa+unsubscr...@dgr.gov.co. ___ 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
Re: [Talk-co] EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA - Comunicado de prensa N° 202
+1 El 22 de diciembre de 2014, 18:45, Fredy Rivera fredyriv...@gmail.com escribió: Hola maperos El dia de mañana estará en la zona Carlos Andres barrera (Puentero) quien nos solicita que colaboremos en el mapeo de la zona. Carlos pertenece a Unidad Nacional para la Gestión del Riesgo de Desastres y fue precisamente quien hizo famoso el mapa de OSM en la atención del terremoto en Haiti. Les parece si organizamos un task y nos ponemos en la tarea? salu2 Humano 2014-12-22 10:37 GMT-05:00 Gestión del Riesgo de Desastres Ungrd comunicacio...@gestiondelriesgo.gov.co: *Comunicado de prensa N° 202* *Bogotá 22 de diciembre de 2014* *EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA* *El evento sucedió en la madrugada del domingo, como consecuencia de las lluvias que se presentaron al sur del Departamento e involucró a los ríos San Bingo y Mazamorras* *22 de diciembre de 2014. *Desde el momento de la emergencia sucedida a raíz de las lluvias presentadas en la tarde del sábado y la madrugada del domingo, el Sistema Nacional de Gestión del Riesgo de Desastres se activó para brindar atención a la emergencia que dejó a su paso 3 personas fallecidas, 50 casas afectadas y destrucción de 6 puentes vehiculares y 4 peatonales en los municipios de Mercaderes y Bolívar. Tras la coordinación del nivel Municipal, Departamental y Nacional y bajo el conocimiento del Presidente de la República, un equipo técnico de la Unidad Nacional para la Gestión del Riesgo de Desastres, UNGRD, se desplazó a la zona para la determinación de daños y análisis de necesidades, para adelantar las acciones de atención, resumidas así: - Activación del Sistema Nacional de Gestión del Riesgo - Acciones de Búsqueda y Rescate - Movilización del Batallón de Ingenieros del Ejército Nacional - Disposición de Banco de Maquinaria del Departamento - Evaluación de daños para la recuperación de puntos críticos - Coordinación del nivel Municipal, Departamental y Nacional En el día de mañana, el Director de la UNGRD, Carlos Iván Márquez Pérez, estará haciendo un recorrido de verificación por los municipios de Mercaderes y Bolívar y la entrega de ayudas de Asistencia Humanitaria de Emergencia, relativas a kits de mercado y materiales para la recuperación de viviendas. Seguiremos informando. *Diana Londoño* – Jefe Oficina Asesora de Comunicaciones 3124483908 diana.lond...@gestiondelriesgo.gov.co *Oficina Asesora de Comunicaciones* Unidad Nacional para la Gestión del Riesgo de Desastres *Teléfono:* 5529696 Ext.500 Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a prensa+unsubscr...@dgr.gov.co. ___ 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
Re: [Talk-co] EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA - Comunicado de prensa N° 202
Por lo descrito en el mensaje, tal vez esta pueda ser un acercamiento hacia el área de emergencia http://umap.openstreetmap.co/es/map/untitled-map_201#10/1.8564/-77.0293 El 22 de diciembre de 2014, 19:05, hyan...@gmail.com hyan...@gmail.com escribió: +1 El 22 de diciembre de 2014, 18:45, Fredy Rivera fredyriv...@gmail.com escribió: Hola maperos El dia de mañana estará en la zona Carlos Andres barrera (Puentero) quien nos solicita que colaboremos en el mapeo de la zona. Carlos pertenece a Unidad Nacional para la Gestión del Riesgo de Desastres y fue precisamente quien hizo famoso el mapa de OSM en la atención del terremoto en Haiti. Les parece si organizamos un task y nos ponemos en la tarea? salu2 Humano 2014-12-22 10:37 GMT-05:00 Gestión del Riesgo de Desastres Ungrd comunicacio...@gestiondelriesgo.gov.co: *Comunicado de prensa N° 202* *Bogotá 22 de diciembre de 2014* *EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA* *El evento sucedió en la madrugada del domingo, como consecuencia de las lluvias que se presentaron al sur del Departamento e involucró a los ríos San Bingo y Mazamorras* *22 de diciembre de 2014. *Desde el momento de la emergencia sucedida a raíz de las lluvias presentadas en la tarde del sábado y la madrugada del domingo, el Sistema Nacional de Gestión del Riesgo de Desastres se activó para brindar atención a la emergencia que dejó a su paso 3 personas fallecidas, 50 casas afectadas y destrucción de 6 puentes vehiculares y 4 peatonales en los municipios de Mercaderes y Bolívar. Tras la coordinación del nivel Municipal, Departamental y Nacional y bajo el conocimiento del Presidente de la República, un equipo técnico de la Unidad Nacional para la Gestión del Riesgo de Desastres, UNGRD, se desplazó a la zona para la determinación de daños y análisis de necesidades, para adelantar las acciones de atención, resumidas así: - Activación del Sistema Nacional de Gestión del Riesgo - Acciones de Búsqueda y Rescate - Movilización del Batallón de Ingenieros del Ejército Nacional - Disposición de Banco de Maquinaria del Departamento - Evaluación de daños para la recuperación de puntos críticos - Coordinación del nivel Municipal, Departamental y Nacional En el día de mañana, el Director de la UNGRD, Carlos Iván Márquez Pérez, estará haciendo un recorrido de verificación por los municipios de Mercaderes y Bolívar y la entrega de ayudas de Asistencia Humanitaria de Emergencia, relativas a kits de mercado y materiales para la recuperación de viviendas. Seguiremos informando. *Diana Londoño* – Jefe Oficina Asesora de Comunicaciones 3124483908 diana.lond...@gestiondelriesgo.gov.co *Oficina Asesora de Comunicaciones* Unidad Nacional para la Gestión del Riesgo de Desastres *Teléfono:* 5529696 Ext.500 Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a prensa+unsubscr...@dgr.gov.co. ___ 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
Re: [Talk-co] EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA - Comunicado de prensa N° 202
La alcaldia tiene algo de info que quiza sirva de algo http://bolivar-cauca.gov.co/apc-aa-files/65306439303230366530393436363636/hidrografia_bolivar_2.jpg http://bolivar-cauca.gov.co/apc-aa-files/65306439303230366530393436363636/zona_urbana_1.jpg 2014-12-22 19:57 GMT-05:00 hyan...@gmail.com hyan...@gmail.com: Por lo descrito en el mensaje, tal vez esta pueda ser un acercamiento hacia el área de emergencia http://umap.openstreetmap.co/es/map/untitled-map_201#10/1.8564/-77.0293 El 22 de diciembre de 2014, 19:05, hyan...@gmail.com hyan...@gmail.com escribió: +1 El 22 de diciembre de 2014, 18:45, Fredy Rivera fredyriv...@gmail.com escribió: Hola maperos El dia de mañana estará en la zona Carlos Andres barrera (Puentero) quien nos solicita que colaboremos en el mapeo de la zona. Carlos pertenece a Unidad Nacional para la Gestión del Riesgo de Desastres y fue precisamente quien hizo famoso el mapa de OSM en la atención del terremoto en Haiti. Les parece si organizamos un task y nos ponemos en la tarea? salu2 Humano 2014-12-22 10:37 GMT-05:00 Gestión del Riesgo de Desastres Ungrd comunicacio...@gestiondelriesgo.gov.co: *Comunicado de prensa N° 202* *Bogotá 22 de diciembre de 2014* *EN CAUCA, ATENCIÓN A EMERGENCIA TRAS AVALANCHA* *El evento sucedió en la madrugada del domingo, como consecuencia de las lluvias que se presentaron al sur del Departamento e involucró a los ríos San Bingo y Mazamorras* *22 de diciembre de 2014. *Desde el momento de la emergencia sucedida a raíz de las lluvias presentadas en la tarde del sábado y la madrugada del domingo, el Sistema Nacional de Gestión del Riesgo de Desastres se activó para brindar atención a la emergencia que dejó a su paso 3 personas fallecidas, 50 casas afectadas y destrucción de 6 puentes vehiculares y 4 peatonales en los municipios de Mercaderes y Bolívar. Tras la coordinación del nivel Municipal, Departamental y Nacional y bajo el conocimiento del Presidente de la República, un equipo técnico de la Unidad Nacional para la Gestión del Riesgo de Desastres, UNGRD, se desplazó a la zona para la determinación de daños y análisis de necesidades, para adelantar las acciones de atención, resumidas así: - Activación del Sistema Nacional de Gestión del Riesgo - Acciones de Búsqueda y Rescate - Movilización del Batallón de Ingenieros del Ejército Nacional - Disposición de Banco de Maquinaria del Departamento - Evaluación de daños para la recuperación de puntos críticos - Coordinación del nivel Municipal, Departamental y Nacional En el día de mañana, el Director de la UNGRD, Carlos Iván Márquez Pérez, estará haciendo un recorrido de verificación por los municipios de Mercaderes y Bolívar y la entrega de ayudas de Asistencia Humanitaria de Emergencia, relativas a kits de mercado y materiales para la recuperación de viviendas. Seguiremos informando. *Diana Londoño* – Jefe Oficina Asesora de Comunicaciones 3124483908 diana.lond...@gestiondelriesgo.gov.co *Oficina Asesora de Comunicaciones* Unidad Nacional para la Gestión del Riesgo de Desastres *Teléfono:* 5529696 Ext.500 Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a prensa+unsubscr...@dgr.gov.co. ___ 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 -- ## |___|__\___ | _ | |_ | } (_) (_) 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-dk] Underlige nye adresser
Jeg undrer mig over nogle af de nys tilkomne adresser. Se fx på: http://www.openstreetmap.org/node/3203750825#map=19/55.66461/12.49675 osak:revision er tom, men hvorfor er den så med? Og er husnummeret virkelig korrekt? husnummeret er 1S, men adresseknuden ligger oveni nr 15 og langt fra nr 1? Og når jeg slår det på AWS, så har punktet adgangspunkt-koordinater: null så hvor kommer positionen fra? -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Underlige nye adresser
Jeg undersøger hvorfor den er placeret der. Jeg kan godt se at den ikke skulle oprettes fordi lat og lon er 0 https://webapi.aws.dk/adresser/Tschernings%20All%C3%A9,1s,2500 Mvh Den 22. december 2014 kl. 19.49 skrev Niels Elgaard Larsen elga...@agol.dk : Jeg undrer mig over nogle af de nys tilkomne adresser. Se fx på: http://www.openstreetmap.org/node/3203750825#map=19/55.66461/12.49675 osak:revision er tom, men hvorfor er den så med? Og er husnummeret virkelig korrekt? husnummeret er 1S, men adresseknuden ligger oveni nr 15 og langt fra nr 1? Og når jeg slår det på AWS, så har punktet adgangspunkt-koordinater: null så hvor kommer positionen fra? -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-gb-westmidlands] Future planned works
Hi Stu, really useful. I see Curzon street station area is on there but not the rest of the proposed HS2 works. Is there a set of rules that dictate what goes on the connected map and when in the planning process? Cheers Andy From: Stuart Lester [mailto:stules...@gmail.com] Sent: 21 December 2014 10:52 To: OSM Group WM Subject: [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-cat] divisió per barris
En principi el que fa és una mena de buffer per proximitat al node de barri. A Sant Vicenç encara en barallo amb els de l'ajuntament perque no existeix cap delimitació oficial dels barris o fins i tot quins barris existeixen en realitat. Lo bo es poser dibuixar els polígons amb la seva delimitació. Den 22 dec 2014 15:07 skrev ferm...@gmx.net: Bona tarda a tots i bones festes!!! s'utilitza algun tipus de divisió pels barris d'una ciutat? des de l'OSMAND a Vic veig que buscant alguna adreça em surt referència al barri, però no sé veure on està indicat, i no passa amb tots els barris. Si sé com fer-ho afegiria la resta de barris de la ciutat ara que els han delimitat bé. Moltes gràcies, Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] divisió per barris
A Vic fa un parell danys que es van delimitar molt acuradament els 14 barris que hi han (o que han creat). Si ho faig amb polgons, quines etiquetes recomanareu? he mirat a la wiki letiqueta place per no mha quedat gens clar si era el que havia dutilitzar. Grcies de nou, Ferm Gesendet:Montag, 22. Dezember 2014 um 16:27 Uhr Von:Carlos Snchez erielk...@gmail.com An:OpenStreetMap in catalan talk-cat@openstreetmap.org Betreff:Re: [Talk-cat] divisi per barris En principi el que fa s una mena de buffer per proximitat al node de barri. A Sant Vicen encara en barallo amb els de lajuntament perque no existeix cap delimitaci oficial dels barris o fins i tot quins barris existeixen en realitat. Lo bo es poser dibuixar els polgons amb la seva delimitaci. Den 22 dec 2014 15:07 skrev ferm...@gmx.net: Bona tarda a tots i bones festes!!! sutilitza algun tipus de divisi pels barris duna ciutat? des de lOSMAND a Vic veig que buscant alguna adrea em surt referncia al barri, per no s veure on est indicat, i no passa amb tots els barris. Si s com fer-ho afegiria la resta de barris de la ciutat ara que els han delimitat b. Moltes grcies, Ferm ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
[Talk-lv] intervija par osm latvijaa
vai ir kaads, kursh veeleetos atbildeet uz dazhiem intervijas jautaajumiem par osm latvijaa ? apmeeram par osm statuss un challenges latvijaa, prognozes... :) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] intervija par osm latvijaa
Kāds bus intervijas formāts? TV, radio, text? On 22.12.2014. 12:26, Rich wrote: vai ir kaads, kursh veeleetos atbildeet uz dazhiem intervijas jautaajumiem par osm latvijaa ? apmeeram par osm statuss un challenges latvijaa, prognozes... :) -- -- Best Regards! Ilja ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-lv] geolatvija
paskatiijos https://geolatvija.lv ... liidz galam nesapratu datu atveertiibas liimeni. cik noderiigs mums shis vareetu buut ? -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] geolatvija
Pagaidām izskatās necik, kad būs vairāk datu tad varēs spriest. Es drīzāk ieteiktu pasekot līdz autortiesību likumam un maģiskajiem 15 gadiem ;) Nu jau brīvi pieejamam vajadzētu būt vecajam, melnbaltajam ortofoto. Ja nemaldos nākošgad vajadzētu būt brīvai un publiski pieejamai satelītkartes pirmajai redakcijai, un tie jau ir vektordati... Priekā! On 22 December 2014 at 13:47, Rich ric...@nakts.net wrote: paskatiijos https://geolatvija.lv ... liidz galam nesapratu datu atveertiibas liimeni. cik noderiigs mums shis vareetu buut ? -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] intervija par osm latvijaa
On 22/12/14 12:39, Ilja Denisovs wrote: Kāds bus intervijas formāts? TV, radio, text? teksts - tie ir 5 jautaajumi mailaa, un man bija doma, ka vareetu vienkaarshi tos + atbildes parsuutiit ieintereseetajiem un tad salikt kopaa On 22.12.2014. 12:26, Rich wrote: vai ir kaads, kursh veeleetos atbildeet uz dazhiem intervijas jautaajumiem par osm latvijaa ? apmeeram par osm statuss un challenges latvijaa, prognozes... :) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] intervija par osm latvijaa
Labi, es varu mēģināt. On 22.12.2014. 16:59, Rich wrote: On 22/12/14 12:39, Ilja Denisovs wrote: Kāds bus intervijas formāts? TV, radio, text? teksts - tie ir 5 jautaajumi mailaa, un man bija doma, ka vareetu vienkaarshi tos + atbildes parsuutiit ieintereseetajiem un tad salikt kopaa On 22.12.2014. 12:26, Rich wrote: vai ir kaads, kursh veeleetos atbildeet uz dazhiem intervijas jautaajumiem par osm latvijaa ? apmeeram par osm statuss un challenges latvijaa, prognozes... :) -- -- Best Regards! Ilja ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-cz] OSM na seznamu
Vypada to, ze seznam zobrazuje OSM podklad, ovsem krome CR. Je na tom poznat, ze to na hranicich nenavazuje a za hranicemi je mapa vyrazne podrobnejsi. http://mapy.cz V paticce (vlevo dole) je odkaz. Pri vetsich zoomech (9+) zobrazuje i ceske nazvy. Od 13+ zacina zobrazovat POI. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] chyba traceru a nefunkční modul ruian tracer
Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM na seznamu
Zajímavé. Škoda, že nedají vrstvu pro OSM data i pro ČR. Ale beru, že se jim nechce zviditelňovat konkurenci :-D -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: Talk-cz@openstreetmap.org Datum: 22. 12. 2014 18:20:48 Předmět: [Talk-cz] OSM na seznamu Vypada to, ze seznam zobrazuje OSM podklad, ovsem krome CR. Je na tom poznat, ze to na hranicich nenavazuje a za hranicemi je mapa vyrazne podrobnejsi. http://mapy.cz V paticce (vlevo dole) je odkaz. Pri vetsich zoomech (9+) zobrazuje i ceske nazvy. Od 13+ zacina zobrazovat POI. ___ 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] Mapování železnic - rozšířené schéma
V příloze posílám první verzi presetu pro kolejovou dopravu. Ocením veškeré připomínky. Návod k používání je zde: http://wiki.openstreetmap.org/wiki/ WikiProject_Czech_Republic/Editing_Standards_and_Conventions#Kolejov.C3.A9_ trat.C4.9B_.28Railway.29 (http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/Editing_Standards_and_Conventions#Kolejov.C3.A9_trat.C4.9B_.28Railway.29) Jednou z věcí, které by bylo ještě potřeba ošetřit, je aktualizace českého překladu JOSM v oblasti železnic. Některé překlady hodnot z combo boxů jsou úplně mimo. Bohužel v překladu JOSM se absolutně nevyznám. Mohl by mi s tím někdo pomoci? Díky, Michal -- Původní zpráva -- Od: Michal Pustějovský michal.pustejov...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 19:48:21 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Díky za pochvalu. Schéma nepochybně šíleně komplexní je (typicky německá preciznost), ovšem na německém základu plánuju vytvořit JOSM presety pro ČR, které tuhle nevýhodu smažou. Bez presetů se tohle schéma normálně používat nedá. Do editing standards to plánuju přidat poté, co se dořeší věci, co jsou pod každou kapitolou v poznámkách (spousta už dořešena a tedy smazána je). Jedná se zejména o to, zda ve značkách operator, network apod. používát prefixy cz:, např cz:SŽDC apod. Tohle třeba sám rozhodnout nedokážu. Michal -- Původní zpráva -- Od: hanoj eha...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 14:10:05 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Ahoj, super práce. Jen se mi to zdá tak komplexní, že pro běžnou praxi prostého uživatele je to neuchopitelné. Ale když základní věci vtělíš do Cz:Map features případně cz /Editing standards tak to snad nějaké ovoce přinese. díky hanoj Dne 12. prosince 2014 15:31 Michal Pustějovský michal.pustejov...@seznam.cz napsal(a): Dobrý den, už nějakou dobu se věnuji překladu tagovacího schématu železniční (resp. kolejové) dopravy z OpenRailwayMap (http://www.openrailwaymap.org/; schéma http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging). Jedná se o schéma vytvořené německou komunitou k přesnému, systematickému a logickému způsobu popisu tamní železniční sítě. Už nyní je v Německu a Rakousku hojně využíváno. Základem schématu je rozšíření dosavadních tagů a způsobů mapování o další detaily. V několika případech je ale zavrhuje, ovšem vždy z dobrých důvodů, které jsou vysvětleny. Rád bych tímto modelem nahradil současný způsob značení českých železnic, který je zastaralý a nekonzistentní. Součástí textu jsou i poznámky a návrhy týkající se věcí, které bych chtěl projednat s komunitou. S radostí uvítám případné dotazy, připomínky, návrhy nebo kritiku. V části týkající se kolejí se jedná prakticky pouze o rozšíření o další specializované tagy, které např. řeší routing. Hlavní změny nastávají v části popisující nádraží a zastávky, kde se snaží skloubit zažité tagování veřejné hromadné dopravy (railway=station atd.) a nový public_transport. Menší změny jsou i v typech relací popisující trasy jak dopravy, tak i dopravní cesty a infrastruktury. Překlad je zde (dostupný zatím pouze odkazem): https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/railway_ tagging. Nejedná se pouze o překlad, ale spíše adaptaci modelu na české prostředí. Přidávám i návrhy hodnot u klíčů typu operator nebo network. Snažím se v poznámkách také komentovat, co by adaptace pro danou oblast znamenala pro současný stav. Překlad není kompletní, protože původní schéma je opravdu až zbytečně detailní, např. obsahuje značení pro železniční signalizaci, podrobný popis systému elektrifikace apod. Pokud by nikdo nebyl proti, nahradil bych tímto schématem kapitolu o železnici v Editting Standards pro ČR. Současně bych začal pracovat i na příkladech. Nakonec bych uvedl, že neexistuje žádná podobně propracovaná alternativa a že toto schéma se již v zahraničí používá. Těším se na příp. dotazy, 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;?xml version=1.0 ? presets xmlns=http://josm.openstreetmap.de/tagging-preset-1.0; description=Železnice a tramvaje v ČR shortdescription=Železnice v ČR group name=Železnice a tramvaje v ČR item name=Hlavní koleje type=way link href=http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/railway_tagging#Koleje/ label text=Upravte nebo vytvořte hlavní železniční koleje./ space/ !-- Delete any operator, network or ref tags, those should
Re: [Talk-cz] chyba traceru a nefunkční modul ruian tracer
Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a): Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí jen zkopírovat do emailu. Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil. Zřejmě se stalo už něco před tím. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapování železnic - rozšířené schéma
Ahoj, napis mi, co potrebujes predelat a ja to tam do JOSM doplnim. Dalibor Sent from my HTC - Reply message - From: Michal Pustějovský michal.pustejov...@seznam.cz To: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Subject: [Talk-cz]Mapování železnic - rozšířené schéma Date: Mon, Dec 22, 2014 19:00 V příloze posílám první verzi presetu pro kolejovou dopravu. Ocením veškeré připomínky. Návod k používání je zde: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/Editing_Standards_and_Conventions#Kolejov.C3.A9_trat.C4.9B_.28Railway.29 Jednou z věcí, které by bylo ještě potřeba ošetřit, je aktualizace českého překladu JOSM v oblasti železnic. Některé překlady hodnot z combo boxů jsou úplně mimo. Bohužel v překladu JOSM se absolutně nevyznám. Mohl by mi s tím někdo pomoci? Díky, Michal -- Původní zpráva -- Od: Michal Pustějovský michal.pustejov...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 19:48:21 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Díky za pochvalu. Schéma nepochybně šíleně komplexní je (typicky německá preciznost), ovšem na německém základu plánuju vytvořit JOSM presety pro ČR, které tuhle nevýhodu smažou. Bez presetů se tohle schéma normálně používat nedá. Do editing standards to plánuju přidat poté, co se dořeší věci, co jsou pod každou kapitolou v poznámkách (spousta už dořešena a tedy smazána je). Jedná se zejména o to, zda ve značkách operator, network apod. používát prefixy cz:, např cz:SŽDC apod. Tohle třeba sám rozhodnout nedokážu. Michal -- Původní zpráva -- Od: hanoj eha...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 14:10:05 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Ahoj, super práce. Jen se mi to zdá tak komplexní, že pro běžnou praxi prostého uživatele je to neuchopitelné. Ale když základní věci vtělíš do Cz:Map features případně cz /Editing standards tak to snad nějaké ovoce přinese. díky hanoj Dne 12. prosince 2014 15:31 Michal Pustějovský michal.pustejov...@seznam.cz napsal(a): Dobrý den, už nějakou dobu se věnuji překladu tagovacího schématu železniční (resp. kolejové) dopravy z OpenRailwayMap (http://www.openrailwaymap.org/; schéma http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging). Jedná se o schéma vytvořené německou komunitou k přesnému, systematickému a logickému způsobu popisu tamní železniční sítě. Už nyní je v Německu a Rakousku hojně využíváno. Základem schématu je rozšíření dosavadních tagů a způsobů mapování o další detaily. V několika případech je ale zavrhuje, ovšem vždy z dobrých důvodů, které jsou vysvětleny. Rád bych tímto modelem nahradil současný způsob značení českých železnic, který je zastaralý a nekonzistentní. Součástí textu jsou i poznámky a návrhy týkající se věcí, které bych chtěl projednat s komunitou. S radostí uvítám případné dotazy, připomínky, návrhy nebo kritiku. V části týkající se kolejí se jedná prakticky pouze o rozšíření o další specializované tagy, které např. řeší routing. Hlavní změny nastávají v části popisující nádraží a zastávky, kde se snaží skloubit zažité tagování veřejné hromadné dopravy (railway=station atd.) a nový public_transport. Menší změny jsou i v typech relací popisující trasy jak dopravy, tak i dopravní cesty a infrastruktury. Překlad je zde (dostupný zatím pouze odkazem): https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/railway_tagging. Nejedná se pouze o překlad, ale spíše adaptaci modelu na české prostředí. Přidávám i návrhy hodnot u klíčů typu operator nebo network. Snažím se v poznámkách také komentovat, co by adaptace pro danou oblast znamenala pro současný stav. Překlad není kompletní, protože původní schéma je opravdu až zbytečně detailní, např. obsahuje značení pro železniční signalizaci, podrobný popis systému elektrifikace apod. Pokud by nikdo nebyl proti, nahradil bych tímto schématem kapitolu o železnici v Editting Standards pro ČR. Současně bych začal pracovat i na příkladech. Nakonec bych uvedl, že neexistuje žádná podobně propracovaná alternativa a že toto schéma se již v zahraničí používá. Těším se na příp. dotazy, 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] chyba traceru a nefunkční modul ruian tracer
No bohužel log nemám, jak se mi to stalo tak jsem nahrál dosud natrasovaná
data a poté josm zavřel a znovu otevřel a již dále trasování polí fungovalo.
JOSM mám
Ale modul ruian traceru stále nefunguje
když jsem omylem navolil modul traceru RI a klikl do polí, tak se mi
objevila rovněž hláška o chybě traceru
posílám výpis
{{{
Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-12-09 17:17:36
Last Changed Author: Don-vip
Revision:
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-12-09 18:14:49 +0100 (Tue, 09 Dec 2014)
Last Changed Rev:
Identification: JOSM/1.5 ( cs) Windows 7 64-Bit
Memory Usage: 360 MB / 989 MB (49 MB allocated, but free)
Java version: 1.7.0_71, Oracle Corporation, Java HotSpot(TM) Client VM
Dataset consistency test: No problems found
Plugins:
- Tracer-testing (1418711938)
- geotools (30762)
- jts (30762)
- pointInfo (30833)
- reltoolbox (30841)
- reverter (30737)
Last errors/warnings:
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- E: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at java.util.Collections$UnmodifiableList.get(Unknown Source)
at
org.openstreetmap.josm.plugins.tracer.TracerRecord.getBBox(TracerRecord.java:82)
at
org.openstreetmap.josm.plugins.tracer.TracerModule$AbstractTracerTask.realRun(TracerModule.java:206)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:93)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:161)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
}}}
Dne 22. prosince 2014 19:26 Marián Kyral mky...@email.cz napsal(a):
Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a):
Ahoj
Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat
modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a
když jsem chtěl dále pokračovat v trasování polí tak objevila se
hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer
testing.
Pražák
Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z
konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se
zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí
jen zkopírovat do emailu.
Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil.
Zřejmě se stalo už něco před tím.
Marián
___
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] chyba traceru a nefunkční modul ruian tracer
Dne 22.12.2014 v 20:28 Pavel napsal(a): Dne 22.12.2014 v 19:26 Marián Kyral napsal(a): Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a): Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí jen zkopírovat do emailu. Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil. Zřejmě se stalo už něco před tím. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz Můžu taky dotaz? změnilo se něco v nastavení? mně to v celé Praze hlásí: data nejsou dostupná... Díky Pavel Používáš tracer-testing? Zkusil jsem teď RUIAN i LPIS v Praze, oboje mi funguje. Zkontroluj, jestli nemáš v nastavení pluginu zapnuté jiné URL RUIAN serveru. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] chyba traceru a nefunkční modul ruian tracer
Dne 22.12.2014 v 20:57 Martin Švec - OSM napsal(a): Dne 22.12.2014 v 20:28 Pavel napsal(a): Dne 22.12.2014 v 19:26 Marián Kyral napsal(a): Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a): Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí jen zkopírovat do emailu. Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil. Zřejmě se stalo už něco před tím. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz Můžu taky dotaz? změnilo se něco v nastavení? mně to v celé Praze hlásí: data nejsou dostupná... Díky Pavel Používáš tracer-testing? Zkusil jsem teď RUIAN i LPIS v Praze, oboje mi funguje. Zkontroluj, jestli nemáš v nastavení pluginu zapnuté jiné URL RUIAN serveru. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz Díky ...v tom to bylo..moje chyba :( Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] chyba traceru a nefunkční modul ruian tracer
no já tracer testing používám ale hlásí mi nedostupná data (Zkoušeno v uvedené chotiněvsi) nic jsem v nastavení josm neměnil Pražák -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 22. 12. 2014 20:58:52 Předmět: Re: [Talk-cz] chyba traceru a nefunkční modul ruian tracer Dne 22.12.2014 v 20:28 Pavel napsal(a): Dne 22.12.2014 v 19:26 Marián Kyral napsal(a): Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a): Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí jen zkopírovat do emailu. Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil. Zřejmě se stalo už něco před tím. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz Můžu taky dotaz? změnilo se něco v nastavení? mně to v celé Praze hlásí: data nejsou dostupná... Díky Pavel Používáš tracer-testing? Zkusil jsem teď RUIAN i LPIS v Praze, oboje mi funguje. Zkontroluj, jestli nemáš v nastavení pluginu zapnuté jiné URL RUIAN serveru. Martin ___ 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] chyba traceru a nefunkční modul ruian tracer
Zkus totéž co Pavel. Mrkni do nastavení, jestli tam nemáš zadanou
vlastní url. V souvislosti s RuianLands došlo k reorganizaci a
nepodařilo se mi zachovat původní url.
Marián
Dne 22.12.2014 v 20:56 Zdeněk Pražák napsal(a):
No bohužel log nemám, jak se mi to stalo tak jsem nahrál dosud
natrasovaná data a poté josm zavřel a znovu otevřel a již dále
trasování polí fungovalo.
JOSM mám
Ale modul ruian traceru stále nefunguje
když jsem omylem navolil modul traceru RI a klikl do polí, tak se mi
objevila rovněž hláška o chybě traceru
posílám výpis
{{{
Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-12-09 17:17:36
Last Changed Author: Don-vip
Revision:
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-12-09 18:14:49 +0100 (Tue, 09 Dec 2014)
Last Changed Rev:
Identification: JOSM/1.5 ( cs) Windows 7 64-Bit
Memory Usage: 360 MB / 989 MB (49 MB allocated, but free)
Java version: 1.7.0_71, Oracle Corporation, Java HotSpot(TM) Client VM
Dataset consistency test: No problems found
Plugins:
- Tracer-testing (1418711938)
- geotools (30762)
- jts (30762)
- pointInfo (30833)
- reltoolbox (30841)
- reverter (30737)
Last errors/warnings:
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- W: javax.imageio.IIOException: Inconsistent metadata read from stream
- E: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at java.util.Collections$UnmodifiableList.get(Unknown Source)
at
org.openstreetmap.josm.plugins.tracer.TracerRecord.getBBox(TracerRecord.java:82)
at
org.openstreetmap.josm.plugins.tracer.TracerModule$AbstractTracerTask.realRun(TracerModule.java:206)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:93)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:161)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
}}}
Dne 22. prosince 2014 19:26 Marián Kyral mky...@email.cz
mailto:mky...@email.cz napsal(a):
Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a):
Ahoj
Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat
modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a
když jsem chtěl dále pokračovat v trasování polí tak objevila se
hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer
testing.
Pražák
Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log?
Buď z
konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se
zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To
stačí
jen zkopírovat do emailu.
Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil.
Zřejmě se stalo už něco před tím.
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org mailto: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] 50GB disk na 2 dny
Ahoj, co se týká zlobení traceru, tak s tím nemám nic společného, alespoň o tom nevím :). Měl bych prosbu - nepůjčil byste mi někdo cca 50GB disk na rozumně rychlém netu a s rozumným přístupem? Vyšla konečně Postgre 9.4 a už se nemůžu dočkat poloviční velikosti indexů, 3x rychlejších některých operací a nových fíčur. Je to major ugrade, takže se DB musí vydumpovat a pak nahrát zpátky a vydumpovat nemám kam. Rozumným přístupem myslím scp/ssh, nfs, sambu, - ne klikání na cloudu v prohlížeči. Čím rychlejší net, tím kratší doba výpadku. Můžu koupit třeba u Wedosu na měsíc, ale to mi přijde jako zbytečně dlouhá doba, s měsíčním výpadkem nepočítám. Díky, A kdy ten upgrade udělat? -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapování železnic - rozšířené schéma
Ahoj, vypadá to pěkně ;-) Tohle je OK? Marián Dne 22.12.2014 v 19:00 Michal Pustějovský napsal(a): V příloze posílám první verzi presetu pro kolejovou dopravu. Ocením veškeré připomínky. Návod k používání je zde: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/Editing_Standards_and_Conventions#Kolejov.C3.A9_trat.C4.9B_.28Railway.29 Jednou z věcí, které by bylo ještě potřeba ošetřit, je aktualizace českého překladu JOSM v oblasti železnic. Některé překlady hodnot z combo boxů jsou úplně mimo. Bohužel v překladu JOSM se absolutně nevyznám. Mohl by mi s tím někdo pomoci? Díky, Michal -- Původní zpráva -- Od: Michal Pustějovský michal.pustejov...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 19:48:21 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Díky za pochvalu. Schéma nepochybně šíleně komplexní je (typicky německá preciznost), ovšem na německém základu plánuju vytvořit JOSM presety pro ČR, které tuhle nevýhodu smažou. Bez presetů se tohle schéma normálně používat nedá. Do editing standards to plánuju přidat poté, co se dořeší věci, co jsou pod každou kapitolou v poznámkách (spousta už dořešena a tedy smazána je). Jedná se zejména o to, zda ve značkách operator, network apod. používát prefixy cz:, např cz:SŽDC apod. Tohle třeba sám rozhodnout nedokážu. Michal -- Původní zpráva -- Od: hanoj eha...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 14. 12. 2014 14:10:05 Předmět: Re: [Talk-cz] Mapování železnic - rozšířené schéma Ahoj, super práce. Jen se mi to zdá tak komplexní, že pro běžnou praxi prostého uživatele je to neuchopitelné. Ale když základní věci vtělíš do Cz:Map features případně cz /Editing standards tak to snad nějaké ovoce přinese. díky hanoj Dne 12. prosince 2014 15:31 Michal Pustějovský michal.pustejov...@seznam.cz napsal(a): Dobrý den, už nějakou dobu se věnuji překladu tagovacího schématu železniční (resp. kolejové) dopravy z OpenRailwayMap (http://www.openrailwaymap.org/; schéma http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging). Jedná se o schéma vytvořené německou komunitou k přesnému, systematickému a logickému způsobu popisu tamní železniční sítě. Už nyní je v Německu a Rakousku hojně využíváno. Základem schématu je rozšíření dosavadních tagů a způsobů mapování o další detaily. V několika případech je ale zavrhuje, ovšem vždy z dobrých důvodů, které jsou vysvětleny. Rád bych tímto modelem nahradil současný způsob značení českých železnic, který je zastaralý a nekonzistentní. Součástí textu jsou i poznámky a návrhy týkající se věcí, které bych chtěl projednat s komunitou. S radostí uvítám případné dotazy, připomínky, návrhy nebo kritiku. V části týkající se kolejí se jedná prakticky pouze o rozšíření o další specializované tagy, které např. řeší routing. Hlavní změny nastávají v části popisující nádraží a zastávky, kde se snaží skloubit zažité tagování veřejné hromadné dopravy (railway=station atd.) a nový public_transport. Menší změny jsou i v typech relací popisující trasy jak dopravy, tak i dopravní cesty a infrastruktury. Překlad je zde (dostupný zatím pouze odkazem): https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/railway_tagging. Nejedná se pouze o překlad, ale spíše adaptaci modelu na české prostředí. Přidávám i návrhy hodnot u klíčů typu operator nebo network. Snažím se v poznámkách také komentovat, co by adaptace pro danou oblast znamenala pro současný stav. Překlad není kompletní, protože původní schéma je opravdu až zbytečně detailní, např. obsahuje značení pro železniční signalizaci, podrobný popis systému elektrifikace apod. Pokud by nikdo nebyl proti, nahradil bych tímto schématem kapitolu o železnici v Editting Standards pro ČR. Současně bych začal pracovat i na příkladech. Nakonec bych uvedl, že neexistuje žádná podobně propracovaná alternativa a že toto schéma se již v zahraničí používá. Těším se na příp. dotazy, Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org
Re: [Talk-cz] Duchove v Kozojedech. Re: Osmose Česká republika
Dne 22.12.2014 v 20:38 Petr Souček napsal(a): S nulou na začátku jsme si u nás také užili. Jeden stěžovatel ji chtěl dostat přímo do RÚIAN, že před 30ti lety dostal papír s tím, že má číslo 075 a v RÚIAN má jen 75 (č.ev.) ... a byl docela kumšt mu vysvětlit, že mu tam nulu prostě nedáme :-) PS Ale ma na to lejstro a to je svaty, ne? ;D On by se clovek pousmal, kdyby neplatilo, ze uredni siml se pak na podobne kravovine s radosti toci. -Original Message- From: Marián Kyral [mailto:mky...@email.cz] Sent: Sunday, December 21, 2014 11:41 PM To: talk-cz@openstreetmap.org Subject: 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-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] 50GB disk na 2 dny
On Mon, Dec 22, 2014 at 09:35:34PM +0100, Petr Vejsada wrote: Měl bych prosbu - nepůjčil byste mi někdo cca 50GB disk na rozumně rychlém netu a s rozumným přístupem? ahoj, 10GbE staci? ozvi se mi nejak se domluvime +420 731 186 379 (ale nejmensi co mam je tady 2TB, 50GB budu muset nekde do muzea :-D ) -- Tomas Kasparek e-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kaspa...@jabber.cz Bozetechova 1, 612 66web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgpNAIglIJwJq.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr
Excellent, le problème est corrigé. Tout fonctionne parfaitement. Merci ! Effectivement, les multipolygones ne sont pas entièrement chargés. Ça n'est pas très joli dans josm et son validator n'aime pas trop. Cela mis à part, ça ne pose aucun problème dans le cadre de l'intégration des adresses. Du coup, je ne sais même pas si on peut appeler ça un bug. Le 22 déc. 2014 07:47, Vincent de Château-Thierry v...@laposte.net a écrit : 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Adresse
Bonjour, C'est le petit clin d'oeil de Noël! Au-delà de l'aspect politique, on a là à mon avis une des choses à ne pas faire en ce qui concerne les bonnes pratiques de l'adresse (cf dossier de l'AMF 83) http://www.lemonde.fr/politique/article/2014/12/22/a-villejuif-la-place-georges-marchais-debaptisee_4544588_823448.html Les services de secours vont s'amuser! Donat ___ 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
De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net 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.99638 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 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 ? Je la refais ;) Sur le lien que tu donnes on a des rues nommées dans OSM, comme par exemple le Chemin du Coudert : http://www.openstreetmap.org/way/93907722 Côté Cadastre il est nommé Chemin du Coudert sur le plan cadastral. Mais il devient CHEM DU COUDERT VGE LASCHAMPS quand on interroge les parcelles de ce même plan. Et Fantoir liste le même CHEM DU COUDERT VGE LASCHAMPS. Dans BANO, on croise 3 sources : Fantoir, le nom des parcelles du Cadastre, et les noms de voie OSM. Donc ici on cherche à rapprocher : - Chemin du Coudert (OSM) - CHEM DU COUDERT VGE LASCHAMPS (Fantoir : http://cadastre.openstreetmap.fr/fantoir-dev/#insee=63345) - CHEM DU COUDERT VGE LASCHAMPS (Cadastre). Ce que montre en polygones jaunes cette carte : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.740728lon=2.966796 ce sont les endroits où on a détecté, via les données des parcelles du Cadastre, la récurrence d'un suffixe dans une commune donnée. Cette récurrence fait considérer qu'on a à faire à un suffixe, a priori absent des données OSM. Ici, le suffixe est Vge Laschamps (affiché quand on clique sur les polygones). Une fois détecté, on va au moment des rapprochements OSM = Cadastre = Fantoir, ajouter au préalable ce suffixe à tous les noms de voie qui, à la fois : - n'ont pas ce suffixe - et intersectent les polygones jaunes Donc ici, en préparation du rapprochement, les libellés du Fantoir et du Cadastre ne changent pas (ils ont déjà le suffixe) mais le libellé OSM devient : Chemin du Coudert Vge Laschamps. On a donc 3 libellés identiques (on se fiche de la casse et de l'abréviation Chem/Chemin) = le rapprochement se produit, le rouge sur le calque BANO passe en bleu. Évidemment, la surcharge du nom OSM avec le suffixe ne sert que pour le rapprochement, elle n'est pas stockée dans les résultats. Pour revenir au cas précédent (Rue des Thermes Saint-Pierre / La Cassière) tu peux voir que les polygones jaunes La Cassière débordent sur cette rue : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.690647lon=2.99638 alors qu'elle n'a pas de suffixe dans les données du Cadastre. C'est la limite de l'exercice : l'imbrication de voies suffixées et de voies sans suffixe est un bon sujet pour tourner en bourrique. D'où le recours explicite au tag ref:FR: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
Salut Vincent, Même en pratiquant du dégommage de route régulièrement, j'ai parfois du mal à comprendre les différents cas où ça coince, et je suis même à peu près certain de te demander à un moment ou un autre, quelque chose que tu as déjà abordé. Là, l'explication est excellente, j'ai tout compris :-) Je crois que ça mérite d'être collé dans le wiki. Stf Le 22/12/2014 11:37, Vincent de Château-Thierry a écrit : De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net 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.99638 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 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 ? Je la refais ;) Sur le lien que tu donnes on a des rues nommées dans OSM, comme par exemple le Chemin du Coudert : http://www.openstreetmap.org/way/93907722 Côté Cadastre il est nommé Chemin du Coudert sur le plan cadastral. Mais il devient CHEM DU COUDERT VGE LASCHAMPS quand on interroge les parcelles de ce même plan. Et Fantoir liste le même CHEM DU COUDERT VGE LASCHAMPS. Dans BANO, on croise 3 sources : Fantoir, le nom des parcelles du Cadastre, et les noms de voie OSM. Donc ici on cherche à rapprocher : - Chemin du Coudert (OSM) - CHEM DU COUDERT VGE LASCHAMPS (Fantoir : http://cadastre.openstreetmap.fr/fantoir-dev/#insee=63345) - CHEM DU COUDERT VGE LASCHAMPS (Cadastre). Ce que montre en polygones jaunes cette carte : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.740728lon=2.966796 ce sont les endroits où on a détecté, via les données des parcelles du Cadastre, la récurrence d'un suffixe dans une commune donnée. Cette récurrence fait considérer qu'on a à faire à un suffixe, a priori absent des données OSM. Ici, le suffixe est Vge Laschamps (affiché quand on clique sur les polygones). Une fois détecté, on va au moment des rapprochements OSM = Cadastre = Fantoir, ajouter au préalable ce suffixe à tous les noms de voie qui, à la fois : - n'ont pas ce suffixe - et intersectent les polygones jaunes Donc ici, en préparation du rapprochement, les libellés du Fantoir et du Cadastre ne changent pas (ils ont déjà le suffixe) mais le libellé OSM devient : Chemin du Coudert Vge Laschamps. On a donc 3 libellés identiques (on se fiche de la casse et de l'abréviation Chem/Chemin) = le rapprochement se produit, le rouge sur le calque BANO passe en bleu. Évidemment, la surcharge du nom OSM avec le suffixe ne sert que pour le rapprochement, elle n'est pas stockée dans les résultats. Pour revenir au cas précédent (Rue des Thermes Saint-Pierre / La Cassière) tu peux voir que les polygones jaunes La Cassière débordent sur cette rue : http://osm.vdct.free.fr/hameaux/index.html#zoom=18lat=45.690647lon=2.99638 alors qu'elle n'a pas de suffixe dans les données du Cadastre. C'est la limite de l'exercice : l'imbrication de voies suffixées et de voies sans suffixe est un bon sujet pour tourner en bourrique. D'où le recours explicite au tag ref:FR:FANTOIR. 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] Adresse
C'est fait ! (dans OSM). A+ Marc Sibert m...@sibert.fr Le 22 décembre 2014 11:00, Donat ROBAUX dona...@gmail.com a écrit : Bonjour, C'est le petit clin d'oeil de Noël! Au-delà de l'aspect politique, on a là à mon avis une des choses à ne pas faire en ce qui concerne les bonnes pratiques de l'adresse (cf dossier de l'AMF 83) http://www.lemonde.fr/politique/article/2014/12/22/a-villejuif-la-place-georges-marchais-debaptisee_4544588_823448.html Les services de secours vont s'amuser! Donat ___ 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] BANO : pourquoi cette voie n'est pas rapprochée
Peut-être qu'il faut ajouter le village Laschamp comme un découpage manquant dans la commune - si c'est une commune associée, la créer en admin 9, - sinon si c'est un lieu-dit (au sens donné par le zonage cadastral) le mettre en niveau 10 (et sans doute aussi avec un noeud admin_centre pour le village dans les deux cas) Nominatim affichera alors à la fois le no, de la commune (principale), la commune associée éventuelle au niveau 9, le lieu-dit au niveau 10, et la rue et les rapprochements sont possibles. Il semble que le suffixe VGE ... soit ajouté pour lever l'homonymie du no, de rue dans la commune (il y en a des tas à Lille par exemple avec ses communes associées) Après reste à fixer l'outil BANO pour qu'il sache chercher une rue à un niveau admin plus profond que dans la seule commune et résoudre alors les homonymies de rues nécessitant de trouver un autre terme présent dans les noms du FANTOIR (commune associée, village/lieu-dit; zone coutumière en Nouvelle-Calédonie ou à Wallis-et-Futuna; etc.). Le 22 décembre 2014 12:10, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Salut Vincent, Même en pratiquant du dégommage de route régulièrement, j'ai parfois du mal à comprendre les différents cas où ça coince, et je suis même à peu près certain de te demander à un moment ou un autre, quelque chose que tu as déjà abordé. Là, l'explication est excellente, j'ai tout compris :-) Je crois que ça mérite d'être collé dans le wiki. Stf Le 22/12/2014 11:37, Vincent de Château-Thierry a écrit : De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net 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=18; lat=45.690647lon=2.99638 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 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 ? Je la refais ;) Sur le lien que tu donnes on a des rues nommées dans OSM, comme par exemple le Chemin du Coudert : http://www.openstreetmap.org/way/93907722 Côté Cadastre il est nommé Chemin du Coudert sur le plan cadastral. Mais il devient CHEM DU COUDERT VGE LASCHAMPS quand on interroge les parcelles de ce même plan. Et Fantoir liste le même CHEM DU COUDERT VGE LASCHAMPS. Dans BANO, on croise 3 sources : Fantoir, le nom des parcelles du Cadastre, et les noms de voie OSM. Donc ici on cherche à rapprocher : - Chemin du Coudert (OSM) - CHEM DU COUDERT VGE LASCHAMPS (Fantoir : http://cadastre.openstreetmap. fr/fantoir-dev/#insee=63345) - CHEM DU COUDERT VGE LASCHAMPS (Cadastre). Ce que montre en polygones jaunes cette carte : http://osm.vdct.free.fr/hameaux/index.html#zoom=18; lat=45.740728lon=2.966796 ce sont les endroits où on a détecté, via les données des parcelles du Cadastre, la récurrence d'un suffixe dans une commune donnée. Cette récurrence fait considérer qu'on a à faire à un suffixe, a priori absent des données OSM. Ici, le suffixe est Vge Laschamps (affiché quand on clique sur les polygones). Une fois détecté, on va au moment des rapprochements OSM = Cadastre = Fantoir, ajouter au préalable ce suffixe à tous les noms de voie qui, à la fois : - n'ont pas ce suffixe - et intersectent les polygones jaunes Donc ici, en préparation du rapprochement, les libellés du Fantoir et du Cadastre ne changent pas (ils ont déjà le suffixe) mais le libellé OSM devient : Chemin du Coudert Vge Laschamps. On a donc 3 libellés identiques (on se fiche de la casse et de l'abréviation Chem/Chemin) = le rapprochement se produit, le rouge sur le calque BANO passe en bleu. Évidemment, la surcharge du nom OSM avec le suffixe ne sert que pour le rapprochement, elle n'est pas stockée dans les résultats. Pour revenir au cas précédent (Rue des Thermes Saint-Pierre / La Cassière) tu peux voir que les polygones jaunes La Cassière débordent sur cette rue : http://osm.vdct.free.fr/hameaux/index.html#zoom=18; lat=45.690647lon=2.99638 alors qu'elle n'a pas de suffixe dans les données du
Re: [OSM-talk-fr] Adresse
Conserver un old_name quand même ! Sinon on va avoir des tas de gens cherchant encore cette place trouvée dans leurs carnets d'adresse. Espérons aussi que la mairie, en rebaptisant la rue, et changeant les plaques de rue affichera sur les plaques encore l'ancien nom en dessous (mais ça ne se fait pas toujours partout) et mettra une note aussi sur l'index des rues de ses futurs plans imprimés ou en ligne. -- Question: peut-on mettre plusieurs noms séparés par un point-virgule dans old_name=* ou fait-il d'autres clés (du genre old_name:2=* ou old_name_2=*) ? Je n'ai pas encore vu de consensus dégagé sur ce genre de cas, les pratiques varient d'un pays à l'autre ou d'un utilisateur à l'autre et en fin de compte ces clés supplémentaires sont là à titre informatif seulement quand on affiche le détail d'un objet, à condition que l'outil client charge les détails complets d'un objet. Ce qui n'est le cas que des éditeurs (en vue avancée) ou des analyses QA comme Osmose, mais pas le cas des applis destinées aux utlisateurs finaux tels que des navigateurs embarqués (car ces clés sont ignorées et pas importées dans leur format de base de données). Ces clés informatives (parfois nécessaires pourtant pour lever des ambiguités/homonymes) ne sont pas utilisés non plus pour les recherches (Nominatif...), faute de consensus justement, et pas visibles nom plus dans les rendus d'aucune carte (même raison). Le 22 décembre 2014 13:24, Marc SIBERT m...@sibert.fr a écrit : C'est fait ! (dans OSM). A+ Marc Sibert m...@sibert.fr Le 22 décembre 2014 11:00, Donat ROBAUX dona...@gmail.com a écrit : Bonjour, C'est le petit clin d'oeil de Noël! Au-delà de l'aspect politique, on a là à mon avis une des choses à ne pas faire en ce qui concerne les bonnes pratiques de l'adresse (cf dossier de l'AMF 83) http://www.lemonde.fr/politique/article/2014/12/22/a-villejuif-la-place-georges-marchais-debaptisee_4544588_823448.html Les services de secours vont s'amuser! Donat ___ 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] BANO : pourquoi cette voie n'est pas rapprochée
Dégommer du rouge OUI, dégommer de la route NON ! ;) Le 22/12/2014 12:10, Stéphane Péneau a écrit : Salut Vincent, Même en pratiquant du*dégommage de route* régulièrement, j'ai parfois du mal à comprendre les différents cas où ça coince, et je suis même à peu près certain de te demander à un moment ou un autre, quelque chose que tu as déjà abordé. Là, l'explication est excellente, j'ai tout compris :-) Je crois que ça mérite d'être collé dans le wiki. Stf ___ 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 22/12/2014 14:53, Christian Quest a écrit : Dégommer du rouge OUI, dégommer de la route NON ! ;) Ouuupss ! J'avais mal compris, je croyais que maintenant, pour Osm, ce n'était que les adresses qui avait de l'importance :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Orne - communes nouvelles
Bonjour http://www.ouest-france.fr/commune-nouvelle-quatre-communes-au-sud-dargentan-se-regroupent-3076394 Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orne - communes nouvelles
Attention ce sont des communes associées : les 4 communes ne disparaissent pas elles passent au niveau 9; c'est une 5e commune qui est créée au niveau 8. On ne touche pas à la commune chef-lieu de l'association (il est fréquent que des communes associées se dissocient, par exemple quand certaines d'entre elles décident d'une fusion totale, rejetée par les autres. Encore une fois il nous manque plein de communes associées dans OSM parmi les 700 environ recensées. Les communes associées vont se multiplier depuis cette loi (avant 2010 elles avaient plutôt tendance à disparaître mais la montée en puissance des EPCI impsoée par l'Etat les pousse à vouloir garder leur identité non pas en fusionnant réllement mais en formant l'association, d'autant plus que des communes associées ont déjà refusé de joindre l'EPCI choisie par la commune chef-lieu en voulant aller plutôt vers un autre EPCI) Le 22 décembre 2014 18:13, David Crochet david.croc...@free.fr a écrit : Bonjour http://www.ouest-france.fr/commune-nouvelle-quatre- communes-au-sud-dargentan-se-regroupent-3076394 Cordialement -- David Crochet ___ 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] GPS (routier) hors-ligne en HTML5
Salut En complément, un fichier de Rodolphe Quiedeville évaluant la taille nécessaire pour le stockage des tuiles dont la taille dépend du niveau de zoom. http://blog.rodolphe.quiedeville.org/index.php?post/2010/10/Calculateur-espace-disque-tuiles-OpenStreetMap Eric 2014-12-21 22:14 GMT+01:00 Frédéric Bonifas fredericboni...@gmail.com: 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: Required attributions of OpenStreetMap missing in slippy maps of French Wikipedia
Reçu final de la part de département Legal de la Fondation Wikimedia concernant le problème résolu du manque d'attribution sur les cartes OpenStreetMap affichée sur la Wikipédie francophone. (pour les derniers détails concernant la mise en forme encore imparfaite du panneau glssant contenant la carte c'est un autre sujet qui sera réglé plus tard... peut-être). Joyeuses fêtes à tous... Copie ci-dessous pour information. -- Forwarded message -- From: Wikimedia Legal le...@wikimedia.org Date: 2014-12-23 0:00 GMT+01:00 Subject: Re: Required attributions of OpenStreetMap missing in slippy maps of French Wikipedia To: verd...@wanadoo.fr Hi Philippe, Thanks for pointing this out to us. It appears to be fixed, which is excellent. I'll forward along in case we want to comment, though if so, it will probably be delayed until after the holidays because several people are currently out of the office. Best and happy holidays, Jacob Rogers Legal Counsel Wikimedia Foundation NOTICE: This email message and all attachments transmitted with it are intended solely for the use of the addressees and may contain legally privileged, protected, or confidential information. If you have received this message in error, please notify the sender immediately by email reply and please delete this message from your computer and destroy any copies. You must not copy or disclose the contents of this message or any attachment to any other person. On Sat, Dec 20, 2014 at 10:14 AM, Philippe Verdy verd...@wanadoo.fr wrote: For your information. Licence/copyright violation in French Wikipedia. (this is a cross-site issue, involving at least French Wikipedia where it was detected, and Tool Labs). During Christmas holidays, local admins and authors of this bug may not be present. See the issue posted on Meta for reference (this subpage may be redirected, but we are told to post this kind of cross-site issues on Meta as a subpage of the RfC page, related to Wikimedia policies): Requests for comment/Required attributions of OpenStreetMap missing in slippy maps of French Wikipedia https://meta.wikimedia.org/wiki/Requests_for_comment/Required_attributions_of_OpenStreetMap_missing_in_slippy_maps_of_French_Wikipedia Thanks. Happy Christmas (and New Year 2015) to all when you'll read this message. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] 鯖江市の都市計画図が CC BY で公開されました。
みなさま 田村です。 鯖江市の都市計画図（建物）に関してImport-MLでのディスカッションが一旦終了致しました。 それに関して結果をご報告します。 1）変更点修正点 タグに関して下記の点でご指摘を受け変更しました。 堅牢無壁舎 変更前： building = roof building:material = concrete 変更後： building = roof roof:material = concrete 2）インポート時の住所・建物階数情報 インポート時に住所及び建物階数の情報をインポートしないのか？という話がでました。 今回は難しいと返答しました。 Import-MLでの議論を経ましたので、インポートの作業に入ります。 何かご気付き等ありましたら、お早めにご連絡頂ければと思います。 よろしくお願い致します。 ＝ 氏名：田村賢哉（Kenya TAMURA） 所属：NPO法人 伊能社中／名古屋大学大学院環境学研究科 自宅：名古屋市千種区唐山町1丁目55-2タウン唐山B-103号 携帯電話：090-6063-6784 PCメール：erdkunde.1...@gmail.com ＝ 地理歴史デジタル教育の研究と普及活動をしております。 詳しくは http://www.inochu.org/ 2014/12/07 18:12、Kenya TAMURA erdkunde.1...@gmail.com のメール： いいださん 田村です。 ありがとうございます！ あとはImport-MLでの議論とその準備を進めます。 また、堅牢建物などは普通建物が終了後に進める予定です。 今後ともよろしくお願い致します。 ＝ 氏名：田村賢哉（Kenya TAMURA） 所属：NPO法人 伊能社中／名古屋大学大学院環境学研究科 自宅：名古屋市千種区唐山町1丁目55-2タウン唐山B-103号 携帯電話：090-6063-6784 PCメール：erdkunde.1...@gmail.com mailto:erdkunde.1...@gmail.com ＝ 地理歴史デジタル教育の研究と普及活動をしております。 詳しくは http://www.inochu.org/ http://www.inochu.org/ 2014/12/07 14:54、Satoshi IIDA nyamp...@gmail.com mailto:nyamp...@gmail.com のメール： いいだです。 作業ありがとうございます、 おおむね、よいかんじのように思います。 （英語だと、もうちょい手順を細かく書け、 といわれるかもしれませんが） あと、サンプルのファイル名を見ると 対象が普通建物（3001）のみ、ということのようなのですが、 堅牢建物（3002）なども同様の作業をする、ということでよいですよね？ -- Satoshi IIDA mail: nyamp...@gmail.com mailto:nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org mailto:Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] weekly 230 in English is online
The weekly round-up of OSM news, issue # 230, is now available online in English, giving as always a summary of all things happening in the openstreetmap world: http://www.weeklyosm.eu Enjoy! -- ## Manfred ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?
I've frequently wanted to map the trails that peter out for exactly the reason you state. The choices as a mapper seem wrong: 1) Map the trail : thus encouraging use of a flawed route. 2) Don't map the trail. The casual map reader thinks OSM is missing something. Possible solutions include a node type of becomes indistinct, or dead end. How to mark the way is trickier. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
And it has proper credit for osm. Awesome! *Regards,* *Hans* On Sun, Dec 21, 2014 at 6:09 PM, Michael Patrick geodes...@gmail.com wrote: Michaels craft stores http://www.michaels.com/store-locator ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
The company providing the service is Where 2 Get It ( http://www.where2getit.com/ ). They provide maps for store locator functions for a number of companies. For example: Moe's Southwest Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's. OSM is used for the base map with the store location placemarks as an overlay. You can tell that they are not utilizing the OSM data for the store locations because if you look closely you can see that their placemarks don't always line up with the actual locations of the stores in OSM. --Peter On Mon, Dec 22, 2014 at 1:17 AM, Hans De Kryger hans.dekryge...@gmail.com wrote: And it has proper credit for osm. Awesome! *Regards,* *Hans* On Sun, Dec 21, 2014 at 6:09 PM, Michael Patrick geodes...@gmail.com wrote: Michaels craft stores http://www.michaels.com/store-locator ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
On Dec 22, 2014, at 7:36 AM, Peter Dobratz wrote: The company providing the service is Where 2 Get It ( http://www.where2getit.com/ ). They provide maps for store locator functions for a number of companies. For example: Moe's Southwest Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's. OSM is used for the base map with the store location placemarks as an overlay. You can tell that they are not utilizing the OSM data for the store locations because if you look closely you can see that their placemarks don't always line up with the actual locations of the stores in OSM. --Peter I had noticed that the nearest Michael's to me had the pin in the wrong part of the shopping center (I am the one that mapped that Michael's location for OSM and am pretty sure I have it right). Just looked at the Trader Joe's web site and it looks like they are using background map data from NAVTEQ. But they also have the store nearest me in the wrong location. :)___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
On Mon, Dec 22, 2014 at 7:36 AM, Peter Dobratz pe...@dobratz.us wrote: The company providing the service is Where 2 Get It ( http://www.where2getit.com/ ). They provide maps for store locator functions for a number of companies. For example: Moe's Southwest Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's. OSM is used for the base map with the store location placemarks as an overlay. You can tell that they are not utilizing the OSM data for the store locations because if you look closely you can see that their placemarks don't always line up with the actual locations of the stores in OSM. Ironically, Where 2 Get It uses google to display their own location. Go to their about page, http://www.where2getit.com/about/, scroll down to the bottom of the page. The map link under VIsit Us, is a google search. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
I'll be out on a limb and say that the reason is because they know not all locations for a particular business are mapped in OSM and so they don't want to rely on OSM for the actual locations. Which begs the question of why Where 2 Get It doesn't edit OSM themselves to add the locations (which I will answer by saying that W2GI knows that they aren't familiar enough with all the areas to do it properly). -jack On December 22, 2014 10:44:12 AM EST, Tod Fitch t...@fitchdesign.com wrote: On Dec 22, 2014, at 7:36 AM, Peter Dobratz wrote: The company providing the service is Where 2 Get It ( http://www.where2getit.com/ ). They provide maps for store locator functions for a number of companies. For example: Moe's Southwest Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's. OSM is used for the base map with the store location placemarks as an overlay. You can tell that they are not utilizing the OSM data for the store locations because if you look closely you can see that their placemarks don't always line up with the actual locations of the stores in OSM. --Peter I had noticed that the nearest Michael's to me had the pin in the wrong part of the shopping center (I am the one that mapped that Michael's location for OSM and am pretty sure I have it right). Just looked at the Trader Joe's web site and it looks like they are using background map data from NAVTEQ. But they also have the store nearest me in the wrong location. :) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?
On 12/22/14 3:27 AM, Bryce Nesbitt wrote: I've frequently wanted to map the trails that peter out for exactly the reason you state. The choices as a mapper seem wrong: 1) Map the trail : thus encouraging use of a flawed route. 2) Don't map the trail. The casual map reader thinks OSM is missing something. Possible solutions include a node type of becomes indistinct, or dead end. How to mark the way is trickier. perhaps a new access tag.. access=deprecated access=not_recommended something else? richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?
access=use_at_your_own_risk access=two_paths_diverged_in_a_yellow_wood access=choose_wisely access=plugh access=xyzzy ? -jack On December 22, 2014 10:06:15 AM EST, Richard Welty rwe...@averillpark.net wrote: On 12/22/14 3:27 AM, Bryce Nesbitt wrote: I've frequently wanted to map the trails that peter out for exactly the reason you state. The choices as a mapper seem wrong: 1) Map the trail : thus encouraging use of a flawed route. 2) Don't map the trail. The casual map reader thinks OSM is missing something. Possible solutions include a node type of becomes indistinct, or dead end. How to mark the way is trickier. perhaps a new access tag.. access=deprecated access=not_recommended something else? richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?
Access tags seem inappropriate to me in this case. I would only tag the last node as noexit=yes (http://wiki.openstreetmap.org/wiki/Key:noexit) as a way of making clear that the trail does indeed end and hasn't just not been mapped. Leave the rest to the users of the map -- maybe there is actually a great spot for hunting/geocaching/sunbathing/beaver watching/ mushroom foraging at the end of the trail that you just don't know about. Harald. On Mon Dec 22 2014 at 11:54:58 AM Jack Burke burke...@gmail.com wrote: access=use_at_your_own_risk access=two_paths_diverged_in_a_yellow_wood access=choose_wisely access=plugh access=xyzzy ? -jack On December 22, 2014 10:06:15 AM EST, Richard Welty rwe...@averillpark.net wrote: On 12/22/14 3:27 AM, Bryce Nesbitt wrote: I've frequently wanted to map the trails that peter out for exactly the reason you state. The choices as a mapper seem wrong: 1) Map the trail : thus encouraging use of a flawed route. 2) Don't map the trail. The casual map reader thinks OSM is missing something. Possible solutions include a node type of becomes indistinct, or dead end. How to mark the way is trickier. perhaps a new access tag.. access=deprecated access=not_recommended something else? richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Beaver dam? Wrecked bridge? Hallucinatory roads in TIGER?
Bryce writes: I've frequently wanted to map the trails that peter out for exactly the reason you state. The choices as a mapper seem wrong: 1) Map the trail : thus encouraging use of a flawed route. 2) Don't map the trail. The casual map reader thinks OSM is missing something. Possible solutions include a node type of becomes indistinct, or dead end. I have seen mapped (and done so myself) to good effect the tag noexit=yes at the end of such a path. This might or might not render (depends) similar to the German Dead End sign. How to mark the way is trickier. I have used tag trail_visibility [excellent, good, intermediate, bad, horrible, no] in decreasing quality to denote paths which eventually disappear. I appreciate that our wiki characterizes no as mostly pathless and that excellent orientational skills are required. This allows either a turn-back or bushwhacking, as the hiker desires. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retail Example using OSM
It seems like it's a little out of date too, it doesn't include all the buildings in Washington, DC, which were imported a month or so ago. Maybe they get a regular dump or something. In any case, cool to see! Andrew On Mon, Dec 22, 2014 at 11:47 AM, Jack Burke burke...@gmail.com wrote: I'll be out on a limb and say that the reason is because they know not all locations for a particular business are mapped in OSM and so they don't want to rely on OSM for the actual locations. Which begs the question of why Where 2 Get It doesn't edit OSM themselves to add the locations (which I will answer by saying that W2GI knows that they aren't familiar enough with all the areas to do it properly). -jack On December 22, 2014 10:44:12 AM EST, Tod Fitch t...@fitchdesign.com wrote: On Dec 22, 2014, at 7:36 AM, Peter Dobratz wrote: The company providing the service is Where 2 Get It ( http://www.where2getit.com/ ). They provide maps for store locator functions for a number of companies. For example: Moe's Southwest Grill, Safeway, Trader Joe's, Jo-Ann Fabric, Michael's. OSM is used for the base map with the store location placemarks as an overlay. You can tell that they are not utilizing the OSM data for the store locations because if you look closely you can see that their placemarks don't always line up with the actual locations of the stores in OSM. --Peter I had noticed that the nearest Michael's to me had the pin in the wrong part of the shopping center (I am the one that mapped that Michael's location for OSM and am pretty sure I have it right). Just looked at the Trader Joe's web site and it looks like they are using background map data from NAVTEQ. But they also have the store nearest me in the wrong location. :) -- Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- 600,000 DC residents don't have a vote in Congress -- http://www.dcvote.org/ http://www.dcvote.org/about/index.cfm ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
