[OSM-talk] Horse trails. Good examples?
Hi all, Are there good examples of horse trails and horse 'infrastructure' in OpenStreetMap data? Links please? What makes a well-mapped horse trail facility? Parking with horse trailer parking indicated? Blacksmith shop with horseshoe repair, alignment, rotation and balancing? Saloons (it's like a pub so it's probably already mapped) with hitching post, watering trough and poop and scoop bags? Are there renderings that include many or most items of interest to horse riders? Best regards, Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Horse trails. Good examples?
On Sun, 2013-12-22 at 09:18 -0500, Richard Weait wrote: Hi all, Are there good examples of horse trails and horse 'infrastructure' in OpenStreetMap data? Links please? What makes a well-mapped horse trail facility? Parking with horse trailer parking indicated? Blacksmith shop with horseshoe repair, alignment, rotation and balancing? Saloons (it's like a pub so it's probably already mapped) with hitching post, watering trough and poop and scoop bags? Are there renderings that include many or most items of interest to horse riders? Horse trails is an American term, OSM uses the British word bridleway. Bridleways are becoming increasingly mapped as part of the the process of mapping rights of way network. An example of bridleway can be seen here, although they are not hard to find on osm http://www.openstreetmap.org/#map=15/52.7823/-2.8992 Other infrastructure I am not aware of, but thing such as parking do not need to be special for horse boxes, beyond lack of height limit bars. Saloons make me think of the wild west and whiskey and gunfights, do they still exist outside heritage places? It is certainly not uncommon to see horses at pubs, although I have never seen them tied up whilst the owner is inside, usually one stays outside and someone else get the drinks and brings them out. Country pubs will welcome horseriders in the same way they do walkers or cyclists and any pub will provide a bowl of water if asked, whether its for a horse or a dog. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap @Fosdem 2014
Great! Will there be a sizeable OSM contingent at FOSDEM? On Wed, Dec 18, 2013 at 4:30 AM, RatZilla$ ratzil...@gmail.com wrote: Hi all, We just receive confirmation from the FOSDEM Team for a stand. FOSDEM is the Free Open Source Developers European Meeting. Feel free to join us to show our work and see other Floss communities hacks in Brussels 1 2 February 2014. More details here: https://fosdem.org/2014/ Gaël Nous avons reçu la confirmation des organisateurs du FOSDEM d'un stand pour OSM les 1er et 2février 2014. Au plaisir de vous y voir pour échanger avec d'autres communautés du Libre. Gaël ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Horse trails. Good examples?
Hi! Richard Weait wrote Are there good examples of horse trails and horse 'infrastructure' in OpenStreetMap data? Links please? What makes a well-mapped horse trail facility? Can you give a better description of your idea of what constitutes a horse trail facility? I don't think the term is self-explanatory. Richard Weait wrote Are there renderings that include many or most items of interest to horse riders? There is a whole map dedicated to the needs of horse riders (Central Europe). [1] It concentrates on suitable ways, obstacles, watering places and accomodations. Besides bridleways, there is more than 460 route relations of type=horse in Europe. They work the same way as hiking routes. In the wiki there is a rather extensive page on riding facilities and recommendations on how to map them. (German) [2]. bye, Nop [1] www.wanderreitkarte.de [2] https://wiki.openstreetmap.org/wiki/DE:Reiten -- View this message in context: http://gis.19327.n5.nabble.com/Horse-trails-Good-examples-tp5790570p5790595.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Horse trails. Good examples?
An example from Iceland includes these bridleways and stables (two seperate areas, one in each municipality). The racetrack seems to be rendering incorrectly. http://www.openstreetmap.org/#map=15/64.0789/-21.8358 Þann 22.12.2013 16:25, skrifaði Philip Barnes: On Sun, 2013-12-22 at 09:18 -0500, Richard Weait wrote: Hi all, Are there good examples of horse trails and horse 'infrastructure' in OpenStreetMap data? Links please? What makes a well-mapped horse trail facility? Parking with horse trailer parking indicated? Blacksmith shop with horseshoe repair, alignment, rotation and balancing? Saloons (it's like a pub so it's probably already mapped) with hitching post, watering trough and poop and scoop bags? Are there renderings that include many or most items of interest to horse riders? Horse trails is an American term, OSM uses the British word bridleway. Bridleways are becoming increasingly mapped as part of the the process of mapping rights of way network. An example of bridleway can be seen here, although they are not hard to find on osm http://www.openstreetmap.org/#map=15/52.7823/-2.8992 Other infrastructure I am not aware of, but thing such as parking do not need to be special for horse boxes, beyond lack of height limit bars. Saloons make me think of the wild west and whiskey and gunfights, do they still exist outside heritage places? It is certainly not uncommon to see horses at pubs, although I have never seen them tied up whilst the owner is inside, usually one stays outside and someone else get the drinks and brings them out. Country pubs will welcome horseriders in the same way they do walkers or cyclists and any pub will provide a bowl of water if asked, whether its for a horse or a dog. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Horse trails. Good examples?
Thank you, Jóhannes, very helpful. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-is] That Shouldn't Be Possible™ coverage extended to Iceland
Hello Iceland, My GPS trace analyzer, That Shouldn't Be Possible™ has recently extended its reach beyond the british isles benelux to cover Iceland too. Its purpose? To accept a GPS trace of a drive/cycle you've gone for, analyze the journey against the routable OSM database and, if appropriate, say That Shouldn't Be Possible. Used like this, it can find quite a lot of routing problems or road segments missing from the database. It can also be used to take the hard work out of checking the OSM database against your trace after a long journey by flagging up sections that don't quite agree with OSM. Not quite sure whether you've got that complex junction interlinked and tagged right? Have a gps trace or two that traverses it? That Shouldn't Be Possible might be able to help you. An example analysis result can be seen here[1]: I've left a nice great big error (visible as a spike in the plot) in the middle of it as an example where the trace seems to traverse what's marked as a path. I've written a lot more about it on the wiki[2], so I'm not going to duplicate all that blather here. It's still in what I would call a prototype stage, but it works surprisingly well for motorcar traces (less so for bicycle so far, though I would say that's largely the fault of the current state of OSRM's bicycle profile). Even so[3] I encourage mappers to try it out[4] on one of their traces. Merry xmas everybody. robert. [1] http://ris.dev.openstreetmap.org/tsbp-proto/779918/2/2/ [2] http://wiki.openstreetmap.org/wiki/That_Shouldnt_Be_Possible [3] Especially so - I need testers. [4] http://ris.dev.openstreetmap.org/tsbp-proto/ ___ Talk-is mailing list Talk-is@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-is
Re: [Talk-de] ALK+ // Re: 1000 Hausnummern
Am 20.12.2013 07:50, schrieb Michael Reichert: .. ... Gebäudeeinmessungspflicht. Wenn der Häuslebauer der Einmessungspflicht nicht nachkommt Dass neu errichtete Gebäude im ALK-Layer fehlen, kann auch daran liegen, dass der ALK-Layer wahrscheinlich nicht direkt aus den ALK-Hauptdatenbanken gerendert wird. .. Michael Moin! Die Frist für die Gebäudeeinmessung in NRW beträgt 2 Jahre nach Fertigstellung, wenn ich da noch auf dem Laufenden bin. Es könnte aber Druck der kreditgebenden Sparkasse geben, früher zu beweisen, dass der Bau korrekt auf dem richtigen Flurstück steht. Die ALK in NRW heißt inzwischen ALKIS. Es sind nun alle Katasteramtsbezirke umgestellt. Das Verfahren ALK ist nur noch in wenigen Bundesländern im Einsatz und wird in 2 Jahren komplett abgelöst sein. In NRW ist das Katasteramt eine Kreis-Behörde, in vielen anderen Bundesländern eine Landesbehörde. In NRW gibt jedes Katasteramt einmal zum Jahresende seinen Bestand an das Land ab (Geodatenzentrum beim RP-Köln). Die stellen einen zentralen Kartendienst damit zur Verfügung. Einmessungsfrist und Abgabe ans Land können sich also zu maximal 3 Jahren Verzögerung nach Fertigstellung aufsummieren bis ein Gebäude im Landes-Kartendienst erscheint. Es gibt Geoportale der Kreise wo eine tagesaktuelle ALKIS-Liegenschaftskarte enthalten ist. Mit dem Firefox-Plugin WMS inspector kann man Kartendienst und Ebenen darin anzeigen lassen. http://www.adv-online.de -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ALK+ // Re: 1000 Hausnummern
Am 22. Dezember 2013 12:20 schrieb Frank fr...@fotodrachen.de: Die ALK in NRW heißt inzwischen ALKIS. mehr infos hier: http://de.wikipedia.org/wiki/AFIS-ALKIS-ATKIS-Modell Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
On Sat, Dec 21, 2013 at 12:24:04PM -0800, mmd wrote: Ich hatte damals an eine reine Web-Anwendung gedacht, mit der man neben neuen Relationen auch existierende Relationen einfach durch Drag-und-Drop anpassen kann. Also genau so, wie man heute auf osrm.at eine Route mit Start/Ziel und Zwischenpunkten zusammenbaut. Passt das Ergebnis, sollte automatisch die Relation in der OSM-DB aktualisiert werden können. Alle Split-Operationen (die Du wie geschrieben in JOSM händisch machen würdest) würden dann automatisch im Hintergrund erfolgen. Ich warne davor das Automatisch zu machen. Das wird diskussionen geben ohne ende ob denn das sein muss und jeder kleine fehler würde aufgebauscht werden so wie bei allen automatischen aenderungen oder den imports. Für den Update-Fall müsste man zunächst aus den bestehenden Wegen in der Relation eine möglichst minimale Menge an Zwischenpunkten generieren, so dass OSRM wieder ein Routingergebnis entsprechend der Relation erzeugt (sofern dies überhaupt noch möglich ist). Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Sonntag, den 22.12.2013, 12:58 +0100 schrieb Florian Lohoff: On Sat, Dec 21, 2013 at 12:24:04PM -0800, mmd wrote: Ich hatte damals an eine reine Web-Anwendung gedacht, mit der man neben neuen Relationen auch existierende Relationen einfach durch Drag-und-Drop anpassen kann. Also genau so, wie man heute auf osrm.at eine Route mit Start/Ziel und Zwischenpunkten zusammenbaut. Passt das Ergebnis, sollte automatisch die Relation in der OSM-DB aktualisiert werden können. Alle Split-Operationen (die Du wie geschrieben in JOSM händisch machen würdest) würden dann automatisch im Hintergrund erfolgen. Ich warne davor das Automatisch zu machen. Das wird diskussionen geben ohne ende ob denn das sein muss und jeder kleine fehler würde aufgebauscht werden so wie bei allen automatischen aenderungen oder den imports. +1 Die Idee klingt zunächst bestechend. Das Problem ist einmal der berechnete Weg, der Ungenauigkeiten enthalten kann. Das größere Problem sehe ich in der mangelnden Aktualität. Die Editoren arbeiten immer mit topaktuellen Daten, die Router hängen ein paar Tage hinterher. Wenn ich eine Kreuzung umbaue und anschließend die Routen in Ordnung bringen will, nützt mir das wenig. Andererseits halte ich es für unsinnig, das Routing im Editor einbauen zu wollen, denn dann müsste eine viel zu große Datenmenge herunter geladen werden. Für den besseren Weg halte ich eine Weiterentwicklung der Routeneditoren. Im Josm läuft das bei Busrouten schon recht gut. Dazu würde ich vorschlagen, immer für den ersten Wegeabschnitt jeder Busroute eine Role start zu vergeben. Dann kann Josm in den neuen Busrouten die Route entsprechend sortieren. 80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Josm sollte für die neuen Busrouten in der Lage sein, die Route fortlaufend zu sortieren wie jetzt, aber mit Berücksichtigung der start-Role, automatisch forward/backward zu entfernen und die Haltestellen entsprechend der Wege zu sortieren. Da nach dem neuen Schema immer eine stop_position auf dem Weg liegt, sollte es anhand der übereinstimmenden Haltestellennamen und der Entfernung möglich sein, auch die Haltestellen automatisch in die richtige Reihenfolge zu bringen. Wenn Josm auf eine Lücke stößt, wird danach weiter sortiert wie jetzt auch. Der Sprung auf die Lücke ist bereits vorhanden, hier sollte der herunterzuladende Bereich deutlich verkleinert werden. Es reicht, die nächsten 20m im Umkreis zu laden. Wenn der Editor positioniert ist, kann der Mapper eine größere Umgebung manuell herunter laden. Im Moment ist es so, dass man je nach Ausstattung des Rechners nach 5 - 10 Sprüngen erst einmal den Datenpuffer wegschmeißen muss. Das ist überflüssige Zeit und Traffic. Die alten Relationen mögen vordergründig einfacher sein, weil man nach einem Straßenumbau einfach die Wege irgendwo reinschmeißen kann. Übersichtlich sind die Relationen auf keinen Fall. Der Wartungsaufwand ist bei den neuen Relationen sehr viel kleiner, und wenn an Josm noch ein bisschen geschraubt wird, sollte es auch für Anfänger recht einfach sein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
On Sun, Dec 22, 2013 at 02:30:27PM +0100, Wolfgang Hinsch wrote: Die Idee klingt zunächst bestechend. Das Problem ist einmal der berechnete Weg, der Ungenauigkeiten enthalten kann. Das größere Problem sehe ich in der mangelnden Aktualität. Die Editoren arbeiten immer mit topaktuellen Daten, die Router hängen ein paar Tage hinterher. Wenn ich eine Kreuzung umbaue und anschließend die Routen in Ordnung bringen will, nützt mir das wenig. Ich benutze OSRM fuer andere dinge wie Tiefbaugrobplanung und ich baue die OSRM Datenbestände etwa alle 4 Stunden. Andererseits halte ich es für unsinnig, das Routing im Editor einbauen zu wollen, denn dann müsste eine viel zu große Datenmenge herunter geladen werden. Nein - Ich stelle mir irgendwie vor das ich auf einer webseite das zusammenklicke und dann ein osm.xml bekomme was ich mit JOSM aufmache. In dem xml ist eine relation die alle wegeschnipsel beinhaltet. Das kann man dann schnell visuell kontrollieren und fertig. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Das Public-Transport-Plugin kann Routen automatisch sortieren und umdrehen, wenn sie genau falsch herum sortiert sind. Die forward/backward-Rollen sind allerdings für eine eindeutige Sortierung notwendig, vor allem, wenn eine Buslinie z.B. in einem Busbahnhof einen kreisförmigen Weg befährt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 178 10.12.-16.12.2013
Hallo, die Wochennotiz Nr. 178 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2013/12/wochennotiz-nr-178/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Sonntag, den 22.12.2013, 16:51 +0100 schrieb Roland Olbricht: 80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Das Public-Transport-Plugin kann Routen automatisch sortieren und umdrehen, wenn sie genau falsch herum sortiert sind. Die forward/backward-Rollen sind allerdings für eine eindeutige Sortierung notwendig, vor allem, wenn eine Buslinie z.B. in einem Busbahnhof einen kreisförmigen Weg befährt. Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation keine Verzweigungen geben. Wenn die Relation lückenlos ist, kann sie automatisch sortiert werden, ggf. anhand des From-tags. Da die Relationen aber in der Praxis nach einiger Zeit Lücken aufweisen, wäre es gut, wenn JOSM den Anfangsway automatisch erkennen und dann schon einmal sortieren könnte, soweit es geht. Manuell kann man dann auf die Lücken springen und damit auch größere Routen innerhalb weniger Minuten klären. Wenn nur die Suche nach dem Anfang nicht wäre... Ich vergebe inzwischen für den ersten way der Relation die Role start. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] parliamentry, assembly seat boundaries
Lets take the discussion to the wiki. For anyone interested to join in: http://wiki.openstreetmap.org/wiki/Talk:India:Boundaries On Sun, Dec 22, 2013 at 12:36 PM, ヴィカス ヤダヴァ (vikas yadav) mevi...@gmail.com wrote: Hi, my remarks about the proposal (also added in the talk page). Attributes There are few properties of each political boundaries: 1. Elected Person 2. Election Year 3. ECI AC Number (ref number) 4. ECI PC Number (ref number) 5. ECI Ward Number (ref number) We need to support at least these in the attributes of political boundaries to support extensions which can later take data from other source or database. There are many other properties but these are the minimum. Ward boundary Ward members are also elected. Though they dont seem to be in the political boundary. Please suggest. Also, I have to checked other boundaries but even those should support some attributes that help identify that region using govt. assigned ref number for extensions. Thanks. On 21 December 2013 22:01, Arun Ganesh arun.plane...@gmail.com wrote: Thanks Jaisen. I have updated the wiki with the added details you mentioned: http://wiki.openstreetmap.org/wiki/India:Boundaries Please check if anything is missing and update the page as necessary. This is probably the most comprehensive documentation for boundary mapping for any country. If the scheme can accommodate India, it can probably cover any other country too. On Sat, Dec 21, 2013 at 6:27 PM, Jaisen Nedumpala jaisuv...@gmail.comwrote: Hi, Shall I add my ideas on these boundaries? In my vision, The following are the most prominent administrative divisions in India: First set - Administrative boundaries 1. Territorial waters (Exclusive Economic Zone) (as per United Nations Convention on the Law of the Sea) 2. Zones (Interstate council) 3. States and Union Territories (Governer and Chief Minister) 4. Revenue Districts (District Collector) 5. Revenue Divisions (Revenue Divisional Officer) 6. Taluks / Tehsils (Tahsildar) 7. Revenue Villages (Village officer) 8. Survey / Re-survey /Un-survey - field measurement plots and sub divisions Second Set - Legislative boundaries 1. Lok Sabha (Parliament) Constituency [Lok Sabha - MP] 2. Legislative Assembly (Vidhan Sabha) Constituency [States and Union Territories - MLA] Third Set - Local Self Government 1. Rural a. District (Zilla) Panchayat (President and Secretary) i Divisions (Member) b. Development Blocks (Block/Mandal Panchayat) (President and Block Development Officer/Secretary) i Divisions (Member) c. Grama (Village) Panchayat ( Rural Local Authority) (President/Sarpanch and Secretary) i Wards (Member) 2. Urban a. Municipality / Municipal Corporation / Nagar Panchayat (Urban Local Authority) and Metropolitan Region (Mayor and Secretary) i. Zones ii. Wards (Councillor) 3. Cantonment area (Officer in Command) (Don't know it's divisions :( (Military area Local Authority) Fourth Set - Courts and Police 1. Jurisdiction of various courts 2. Police Districts 3. Police Circles 3. Jurisdiction of Police Stations Fifth Set - Miscellaneous 1. Special Economic Zones 2. Coastal Regulation Zone 3. Ecologically Sensitive Areas I think the above listed are the important sets, regarding the administrative divisions of India. Besides these, almost all the government departments of various tiers of administration, have their own internal administrative boundaries. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ - നെടുമ്പാല ജയ്സെന് - ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ (`'·.¸(`'·.¸^¸.·'´)¸.·'´) «´¨`·* . Jaisen . *..´¨`» (¸.·'´(`'·.¸ ¸.·'´)`'·.¸) ¸.·´^.`'·.¸ ¸.·'´ ( `·.¸`·.¸ `·.¸ )`·.¸ ¸.·(´ `·.¸ ¸.·(.·´)`·.¸ ( `v´ ) `v´ ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Arun Ganesh (planemad) http://en.wikipedia.org/wiki/User:Planemad http://j.mp/ArunGanesh ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Arun Ganesh (planemad) http://en.wikipedia.org/wiki/User:Planemad http://j.mp/ArunGanesh ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] calculate area (sqkm) of a boundary
Thanks Arun. Still having trouble. The JOSM measurement plugin does not work on multiple selections of lines as are my borders. And never used QGIS. On 22 December 2013 17:37, Arun Ganesh arun.plane...@gmail.com wrote: On Sun, Dec 22, 2013 at 12:40 PM, ヴィカス ヤダヴァ (vikas yadav) mevi...@gmail.com wrote: Hi, I am trying to calculate the area of a region/boundary in josm and I cant find a good solution. There are plugins doing that but they do that only for full single line region. Not when the region is surrounded from multiple lines. I don't want perfection on this so available mapped accuracy is good enough. Any other tools which can help? This is pretty trivial using QGIS and imported OSM shapefiles. For josm, maybe http://wiki.openstreetmap.org/wiki/JOSM/Plugins/measurement ? Thanks, Vikas ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Arun Ganesh (planemad) http://en.wikipedia.org/wiki/User:Planemad http://j.mp/ArunGanesh ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
[Talk-it] Parcheggio off-road
Nel processare le note su OSM mi sono trovato a che fare con una zona di campagna che non è un vero parcheggio [1], ma che è importante indicare come zona in cui si può lasciare l'auto per procedere a piedi sui sentieri. Secondo voi ha senso indicare comunque amenity=parking surface=unpaved ? Ciao FabC [1] http://www.openstreetmap.org/note/67786#map=16/43.5358/10.3834layers=N ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
Il 12/18/2013 09:42 PM, Martin Koppenhoefer scrisse: +1, highway=pedestrian non è un qualsiasi percorso pedonale, è una _strada_ pedonalizzata, quindi nel caso di Venezia ci sarebbero pocchissimi... Io ho sempre dato per scontato che highway=pedestrian fosse il valore da usare per quelle che in Italia sono definite dal codice della strada come Aree pedonali. Mi pare che il criterio nella scelta tra pedestrian e footway sia questo, non la larghezza o la presenza di negozi, ecc. Anche se Venezia ha delle peculiarita' che rendono piu' complessa la distinzione. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
Il 21/12/2013 20:11, Martin Koppenhoefer ha scritto: 2013/12/21 Paolo Monegato gato.selvad...@gmail.com mailto:gato.selvad...@gmail.com sarebbe meglio decidere caso per caso. Più o meno dovrebbe risultare che la viabilità principale resta pedestrian, mentre quella secondaria diventerebbe footway... si, poi non andrei troppo rigido su un sistema di classificazione secondo i nomi, andrei in generale caso per caso. È che i nomi sono indicativi. Quelli che ho detto che potrebbero essere footway sono percorsi stretti o che non portano da nessuna parte. Mentre gli altri sono più larghi oppure sono percorsi importanti nella viabilità della città. Dunque possono essere utili per una prima scrematura. Già c'era una classificazione a Venezia qualche anno fa ;-) E com'era? Sinceramente non me la ricordo, mi par che una volta fosse tutto footway e poi fu cambiato con pedestrian in seguito a una discussione in lista... ciao Paolo M ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
Già c'era una classificazione a Venezia qualche anno fa ;-) E com'era? Sinceramente non me la ricordo, mi par che una volta fosse tutto footway e poi fu cambiato con pedestrian in seguito a una discussione in lista... Adesso non c'e` nessuna classificazione. Personalmente che siano pedestrian o footway non mi interessa: la mappa e` in ogni caso inutile anche se completa, perche` se devo andare da un posto ad un altro non riconosco le strade principali dai vicolini (ne` io che guardo il rendering ne` il navigatore). Una delle cose che vengono insegnate subito ai mappatori e` che bisogna descrivere la rete di strade, e che la primary potrebbe anche essere non asfaltata in certe regioni del pianeta. Mi pare che questa sia proprio una di tali regioni in cui la primary non e` a 4 corsie. Il tag highway= e` quello principale, se lo sprechiamo per indicare una restrizione di accesso (come ora) non abbiamo alcuna informazione sulla rete. Personalmente in centro a venezia mi aspetto una rete di tertiary, unclassified (== quaternary) e residential. Una cosa insomma che mi permetta di capire dove sono e di portermi muovere con facilita`. Le restrizioni di accesso si possono indicare separatamente, ma se non abbiamo la rete gerarchica la mappa e` inutile. /alessandro, che sa benissimo di essere in minoranza, ma resta convinto ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
2013/12/22 Alessandro Rubini rubini-l...@gnudd.com: Il tag highway= e` quello principale, se lo sprechiamo per indicare una restrizione di accesso (come ora) non abbiamo alcuna informazione sulla rete. Personalmente in centro a venezia mi aspetto una rete di tertiary, unclassified (== quaternary) e residential. Una cosa insomma che mi permetta di capire dove sono e di portermi muovere con facilita`. Le restrizioni di accesso si possono indicare separatamente, ma se non abbiamo la rete gerarchica la mappa e` inutile. totalmente d'accordo con Alessandro. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
2013/12/22 Alessandro Rubini rubini-l...@gnudd.com Personalmente in centro a venezia mi aspetto una rete di tertiary, unclassified (== quaternary) e residential. Una cosa insomma che mi permetta di capire dove sono e di portermi muovere con facilita`. io sono contrario a mettere tertiary e unclassified per dei percorsi unicamente pedonali, senza possibilità fisica di accedere in macchina, senza macchine presenti, ecc. Se la mappa è completa è automaticamente utile perché il motore di routing ti porta dove vuoi sulla strada più breve. Metterei i percorsi principali come pedestrian, tranne quelli più stretti di 2-3 metri, ed ovviamente i larghi e le piazze (nodi coincidenti con gli edifici in questi casi). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tutto pedestrian a Venezia?
2013/12/22 Paolo Monegato gato.selvad...@gmail.com Già c'era una classificazione a Venezia qualche anno fa ;-) E com'era? Sinceramente non me la ricordo si dovrebbe trovare ancora nello storico... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] SkiMap Garmin
http://gis.19327.n5.nabble.com/file/n5790556/Cattura.jpg ...anche garmin sta usando i dati osm per creare le proprie mappe...almeno così mi sembra analizzando la mia zona ... ...la si può scaricare gratuitamente da qua http://www.garmin.com/it/sport-invernali -- View this message in context: http://gis.19327.n5.nabble.com/SkiMap-Garmin-tp5790556.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] SkiMap Garmin
2013/12/22 scratera piz...@alice.it: http://gis.19327.n5.nabble.com/file/n5790556/Cattura.jpg ...anche garmin sta usando i dati osm per creare le proprie mappe...almeno così mi sembra analizzando la mia zona ... ...la si può scaricare gratuitamente da qua http://www.garmin.com/it/sport-invernali Direi che da qui https://static.garmincdn.com/shared/it/landing-pages/inverno-garmin/EULA-SW-OSM.pdf puoi toglierti il dubbio: ne fanno uso. -- E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , lorenzetto.l...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Parcheggio off-road
Si. Ciao /niubii/ Il 22/dic/2013 10:24 Fabrizio Carrai fabrizio.car...@gmail.com ha scritto: Nel processare le note su OSM mi sono trovato a che fare con una zona di campagna che non è un vero parcheggio [1], ma che è importante indicare come zona in cui si può lasciare l'auto per procedere a piedi sui sentieri. Secondo voi ha senso indicare comunque amenity=parking surface=unpaved ? Ciao FabC [1] http://www.openstreetmap.org/note/67786#map=16/43.5358/10.3834layers=N ___ 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] SkiMap Garmin
...mi era sfuggito il tutto... -- View this message in context: http://gis.19327.n5.nabble.com/SkiMap-Garmin-tp5790556p5790561.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
[Talk-it] Bivacco con fuoco
Nel caso di struttura denominata Bivacco XY di solito io taggo con *tourism=wilderness_hut* oppure se si tratta ad esempio di un eremo (quindi chiesa) che offre anche un piccolo locale che rimane sempre aperto per gli escursionisti lo taggo con *amenity=shelter*. In entrambi i casi se c'è la presenza di un camino e quindi la possibilità di accendere un fuoco può andar bene *fireplace=yes*? Grazie. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Bivacco-con-fuoco-tp5790572.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] SkiMap Garmin
Quindi si tratta del secondo prodotto Garmin su base di OSM. Vedi [Talk-it] Garmin Edge Touring con mappa OSM del 7 settembre 2013 Volker On 22 December 2013 14:03, scratera piz...@alice.it wrote: ...mi era sfuggito il tutto... -- View this message in context: http://gis.19327.n5.nabble.com/SkiMap-Garmin-tp5790556p5790561.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 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bivacco con fuoco
-Original Message- From: demon.box [mailto:e.rossin...@alice.it] Sent: domenica 22 dicembre 2013 15:38 To: talk-it@openstreetmap.org Subject: [Talk-it] Bivacco con fuoco Nel caso di struttura denominata Bivacco XY di solito io taggo con *tourism=wilderness_hut* oppure se si tratta ad esempio di un eremo (quindi chiesa) che offre anche un piccolo locale che rimane sempre aperto per gli escursionisti lo taggo con *amenity=shelter*. In entrambi i casi se c'è la presenza di un camino e quindi la possibilità di accendere un fuoco può andar bene *fireplace=yes*? Per una struttura taggata tourism=wilderness_hut, la possibilità di riscaldarlo e di cucinare (stufa o camino) è implicita. In caso contrario è più adatto amenity=shelter + shelter_type=basic_hut. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Bivacco con fuoco
scusa ma quindi intendi che se c'è un camino NON può essere amenity=shelter? il mio esempio concreto è l'Eremo di San Vigilio che ha annessa una piccola stanzetta con un tavolo, 2 panche ed un fuoco: *tourism=wilderness_hut* mi sembrerebbe troppo perché non è esattamente un bivacco dove pernottare ma è soltanto un ricovero per poche ore o per situazioni di emergenza. ecco perché pensavo ad *amenity=shelter* + *fireplace=yes* che dite? grazie --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Bivacco-con-fuoco-tp5790572p5790597.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] Parcheggio off-road
Ho guardato il posto. Si tratta di un parcheggio molto informale. In più mi sono permesso di cambiare la stradina da driveway a unclassified più surface=unpaved e ho aggiunto la larghezza. Domanda: http://www.openstreetmap.org/way/44934251 mi sembra di access=private. Al cancello c'è un cartello vietato accesso ecc. O sbaglio? Volker 2013/12/22 Fabrizio Carrai fabrizio.car...@gmail.com Nel processare le note su OSM mi sono trovato a che fare con una zona di campagna che non è un vero parcheggio [1], ma che è importante indicare come zona in cui si può lasciare l'auto per procedere a piedi sui sentieri. Secondo voi ha senso indicare comunque amenity=parking surface=unpaved ? Ciao FabC [1] http://www.openstreetmap.org/note/67786#map=16/43.5358/10.3834layers=N ___ 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] Bivacco con fuoco
-Original Message- From: demon.box [mailto:e.rossin...@alice.it] Sent: domenica 22 dicembre 2013 18:55 To: talk-it@openstreetmap.org Subject: Re: [Talk-it] Bivacco con fuoco scusa ma quindi intendi che se c'è un camino NON può essere amenity=shelter? No, volevo dire che in tourism=wilderness_hut si da per scontato che ci sia camino o stufa o qualcosa per scaldare e cucinare, anche se non lo indichi esplicitamente. il mio esempio concreto è l'Eremo di San Vigilio che ha annessa una piccola stanzetta con un tavolo, 2 panche ed un fuoco: *tourism=wilderness_hut* mi sembrerebbe troppo perché non è esattamente un bivacco dove pernottare ma è soltanto un ricovero per poche ore o per situazioni di emergenza. ecco perché pensavo ad *amenity=shelter* + *fireplace=yes* che dite? grazie Si, mi sembra vada bene. Dalla descrizione che ne fai, forse potresti aggiungere shelter_type=weather_shelter. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il giorno 21 dicembre 2013 15:54, Cascafico Giovanni cascaf...@gmail.comha scritto: Mi pare che alcuni articoli non abbiano connotazioni geografiche: Regione fvg duemila grotte O ne ebbero e le tracce sono scomparse, ben oltre il disused: Ferrovia cividale - caporetto cascafico, Daniele e Fabrizio ho aggiornato gli articoli non mappabili con le vostre segnalazioni, grazie. Ciao, Simone F. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] Cómoseñalizar una bodega
Hola. Tengo una pregunta. ¿Existe algo para las instalaciones agroindustriales tales como bodegas,almazaras, sidrerías, etc ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-Talk-ZA] That Shouldn't Be Possible™ coverage extended to South Africa
That sounds really awesome! I'll have to try it out. Sent from a mobile device. On 22 Dec 2013 19:25, Robert Scott li...@humanleg.org.uk wrote: Hello Iceland, My GPS trace analyzer, That Shouldn't Be Possible™ has recently extended its reach beyond the british isles benelux to cover South Africa too. Its purpose? To accept a GPS trace of a drive/cycle you've gone for, analyze the journey against the routable OSM database and, if appropriate, say That Shouldn't Be Possible. Used like this, it can find quite a lot of routing problems or road segments missing from the database. It can also be used to take the hard work out of checking the OSM database against your trace after a long journey by flagging up sections that don't quite agree with OSM. Not quite sure whether you've got that complex junction interlinked and tagged right? Have a gps trace or two that traverses it? That Shouldn't Be Possible might be able to help you. An example analysis result can be seen here[1]: I've left a nice great big error (visible as a spike in the plot) in the middle of it as an example where the trace seems to traverse what's marked as a path. I've written a lot more about it on the wiki[2], so I'm not going to duplicate all that blather here. It's still in what I would call a prototype stage, but it works surprisingly well for motorcar traces (less so for bicycle so far, though I would say that's largely the fault of the current state of OSRM's bicycle profile). Even so[3] I encourage mappers to try it out[4] on one of their traces. Merry xmas everybody. robert. [1] http://ris.dev.openstreetmap.org/tsbp-proto/779918/2/2/ [2] http://wiki.openstreetmap.org/wiki/That_Shouldnt_Be_Possible [3] Especially so - I need testers. [4] http://ris.dev.openstreetmap.org/tsbp-proto/ ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
Re: [OSM-Talk-ZA] That Shouldn't Be Possible™ coverage extended to South Africa
On Sunday 22 December 2013, Robert Scott wrote: Hello Iceland, Damn it. robert. ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
[Talk-cz] Chybejici rybniky v Dibavod importu?
Ahoj, nevite nekdo, zda import rybniku z Dibavodu probehl kompletne, nebi nekde zbyla nejaka data, ktera se neimportovala? Nasel jsem nejake chybejici rybniky. Puvodne jsem si myslel, ze treba drive existovaly, ale nekdo je smazal, ale v historii jsem nedokazal nic najit. Zajimave je, ze se jedna o rybniky, na kterych jsou ostrovy, takze asi byly datove slozitejsi. Jedna se treba o dibavod:id 106030770001 106030350001 Černá 108030795003 Bělohůrecký rybník Díky za odpověď, Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Chybejici rybniky v Dibavod importu?
pokud vím tak import rybníků z dat dibavodu proběhl kompletně, je však pravda, že některé rybníky v datech pro import chyběly a naopak byly v datech pro import i některé neexistující rybníky Pražák Dne 22. prosince 2013 16:42 Dalibor Jelínek dali...@dalibor.cz napsal(a): Ahoj, nevite nekdo, zda import rybniku z Dibavodu probehl kompletne, nebi nekde zbyla nejaka data, ktera se neimportovala? Nasel jsem nejake chybejici rybniky. Puvodne jsem si myslel, ze treba drive existovaly, ale nekdo je smazal, ale v historii jsem nedokazal nic najit. Zajimave je, ze se jedna o rybniky, na kterych jsou ostrovy, takze asi byly datove slozitejsi. Jedna se treba o dibavod:id 106030770001 106030350001 Černá 108030795003 Bělohůrecký rybník Díky za odpověď, Dalibor ___ 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
[OSM-talk-fr] codes postaux...
Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 09:44, Christian Quest a écrit : Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! Ben ya la source officiel de la Poste http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Mais c'est un formulaire Web Sinon j'ai déjà constaté à quelques reprises que les infos de la poste divergeait des infos compilé par galichon.com Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe pas... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Merci d'avance ! Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Je viens de jeter un coup d’œil. Comme on dit, on ne taggue pas pour le rendu mais quand il y en a un qui exploite nos données, c'est quand même plus cool. Donc, concernant le ski de fond: - C'est marrant les petits triangles de danger sur les pistes. Ça correspond aux secteurs pentus? C'est un calcul automatique avec un MNT? - Ça serait sympa d'avoir une indication du sens de parcours des pistes. - Les pistes de chien de traineau n'apparaissent pas (que j'ai codé en piste:type=sleigh) - Même si je comprends que tu veuilles distinguer le ski alpin du ski de fond, c'est dommage que les codes de couleur des pistes de fond n’apparaissent pas dans le rendu plutôt que des motifs (non légendés qui plus est). En ski alpin: - les couleurs des pistes sont un peu ternes alors que (en France au moins), ce sont des couleurs pétantes sur les panneaux. En général: - La légende n'est pas très parlante, faute de textes explicatifs. - À force de naviguer, mon navigateur (firefox 24.2.0 esr) affiche des trucs bizarres. Il y a un truc qui a du planter. Bonnes vacances :-p Eric --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Pour les pistes de fond, les icônes 'danger' correspondent à piste:difficulty. Par contre, les pistes de fond sont colorées selon le tag color des relations route=piste dont elles sont membres. Il y a pas mal d'exemple dans le Jura. C'est justement pour pas taguer pour le rendu: une section difficile sur une piste bleue, ça existe ! Ah oui, piste:type=sleigh. C'est pas la première fois qu'on me fait la remarque. Je crois n'avoir pas été très informé de la définition sur le wiki, il faut que je me repose la question. Traîneaux à chiens pour le grand nord, à cheval pour les touristes en station? Ca me semble assez différent. Pour la legende, j'essaie de pas trop mettre de texte à cause des traductions. Il faudrait au moins mettre les tags d'une manière ou d'une autre. Pour les couleurs ternes, c'est ma fois assez difficile de faire quelque chose d'agreable alors que je ne maîtrise pas la couleur du fond. Quelqu'un d'autre pense pareil ? Pour FF, j'ai eu aussi quelques plantages inexpliqués dernièrement. A creuser. Yves yvecai yve...@gmail.com a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Merci d'avance ! Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Maintenant que tout les codes postaux des communes françaises sont dans OSM, que dites-vous d'harmoniser tout ça ? Il y a actuellement 2 tags utilisés sur les relations des communes: - addr:postcode - postal_code Le wiki indique que les tags addr:* sont à utiliser pour indiquer les adresses et que postal_code=* est à utiliser pour indiquer le code postal correspondant à une zone. La distinction me semble utile. Il semble donc logique d'utiliser postal_code=* sur les relations si l'on suit le wiki. Le problème, c'est que dans la très grande majorité, ce sont actuellement des addr:postcode=* qui figurent sur les relations des communes françaises: - 25518+33531 addr:postcode=* sur les relations + nœuds place=* - 19+618 postal_code=* sur les relations + noeuds place=* Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.org/keys/postal_code#map Je serais bien tenté de passer en postal_code les addr:postcode=* qu'on a actuellement sur les relations des communes pour être cohérent à l'international et pour bien distinguer une zone de code postal avec le code postal d'une adresse, mais n'y a-t-il pas de risque pour les réutilisateurs hexagonaux qui se sont (faussement) basés sur addr:postcode=* ? Qu'en dites-vous ? -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Très chouette le layer enneigement ! Tu as jeté un oeil des données de mon pote d'OpenMeteoData pour les prévisions météo et la couverture neigeuse ? Le 22 décembre 2013 11:02, Yves yve...@gmail.com a écrit : Pour les pistes de fond, les icônes 'danger' correspondent à piste:difficulty. Par contre, les pistes de fond sont colorées selon le tag color des relations route=piste dont elles sont membres. Il y a pas mal d'exemple dans le Jura. C'est justement pour pas taguer pour le rendu: une section difficile sur une piste bleue, ça existe ! Ah oui, piste:type=sleigh. C'est pas la première fois qu'on me fait la remarque. Je crois n'avoir pas été très informé de la définition sur le wiki, il faut que je me repose la question. Traîneaux à chiens pour le grand nord, à cheval pour les touristes en station? Ca me semble assez différent. Pour la legende, j'essaie de pas trop mettre de texte à cause des traductions. Il faudrait au moins mettre les tags d'une manière ou d'une autre. Pour les couleurs ternes, c'est ma fois assez difficile de faire quelque chose d'agreable alors que je ne maîtrise pas la couleur du fond. Quelqu'un d'autre pense pareil ? Pour FF, j'ai eu aussi quelques plantages inexpliqués dernièrement. A creuser. Yves yvecai yve...@gmail.com a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Merci d'avance ! Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 12:23, Christian Quest a écrit : Maintenant que tout les codes postaux des communes françaises sont dans OSM, que dites-vous d'harmoniser tout ça ? Il y a actuellement 2 tags utilisés sur les relations des communes: - addr:postcode - postal_code Le wiki indique que les tags addr:* sont à utiliser pour indiquer les adresses et que postal_code=* est à utiliser pour indiquer le code postal correspondant à une zone. La distinction me semble utile. Il semble donc logique d'utiliser postal_code=* sur les relations si l'on suit le wiki. La dernière modification du wiki est juste pour cette explication que je trouve foireuse. Le problème, c'est que dans la très grande majorité, ce sont actuellement des addr:postcode=* qui figurent sur les relations des communes françaises: - 25518+33531 addr:postcode=* sur les relations + nœuds place=* - 19+618 postal_code=* sur les relations + noeuds place=* Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.org/keys/postal_code#map comparé au 15 millions d'addr:postcode c'est peanuts. Je serais bien tenté de passer en postal_code les addr:postcode=* qu'on a actuellement sur les relations des communes pour être cohérent à l'international et pour bien distinguer une zone de code postal avec le code postal d'une adresse, mais n'y a-t-il pas de risque pour les réutilisateurs hexagonaux qui se sont (faussement) basés sur addr:postcode=* ? Je suis d'avis d'utiliser partout addr:postcode Il y a un schéma relativement complet concernant l’adressage, utilisons -le. postal_code est une vielle balise obsolète. La France doit être moteur des bonnes pratiques ;o) Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Pour la couverture neigeuse, Modis propose un jeu de données ou je pourrais gagner 2-3 niveaux de zoom, c'est prévu. Après, les données sont fraiches à 2 semaines, donc les faibles zooms ça va bien. Si je mets vraiment des données actualisées, il faut vraiment qu'elles soient bonnes: les skieurs sont super exigeants. Franchement, à part les forums locaux, j'ai pas trouvé mieux. Je préfèrerais autant qu'eux se servent de la carte in fine. Yves Christian Quest cqu...@openstreetmap.fr a écrit : Très chouette le layer enneigement ! Tu as jeté un oeil des données de mon pote d'OpenMeteoData pour les prévisions météo et la couverture neigeuse ? Le 22 décembre 2013 11:02, Yves yve...@gmail.com a écrit : Pour les pistes de fond, les icônes 'danger' correspondent à piste:difficulty. Par contre, les pistes de fond sont colorées selon le tag color des relations route=piste dont elles sont membres. Il y a pas mal d'exemple dans le Jura. C'est justement pour pas taguer pour le rendu: une section difficile sur une piste bleue, ça existe ! Ah oui, piste:type=sleigh. C'est pas la première fois qu'on me fait la remarque. Je crois n'avoir pas été très informé de la définition sur le wiki, il faut que je me repose la question. Traîneaux à chiens pour le grand nord, à cheval pour les touristes en station? Ca me semble assez différent. Pour la legende, j'essaie de pas trop mettre de texte à cause des traductions. Il faudrait au moins mettre les tags d'une manière ou d'une autre. Pour les couleurs ternes, c'est ma fois assez difficile de faire quelque chose d'agreable alors que je ne maîtrise pas la couleur du fond. Quelqu'un d'autre pense pareil ? Pour FF, j'ai eu aussi quelques plantages inexpliqués dernièrement. A creuser. Yves yvecai yve...@gmail.com a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Merci d'avance ! Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Salut, Le 22/12/2013 10:02, Christophe Merlet a écrit : Le 22/12/2013 09:44, Christian Quest a écrit : Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! Ben ya la source officiel de la Poste http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Mais c'est un formulaire Web Sinon j'ai déjà constaté à quelques reprises que les infos de la poste divergeait des infos compilé par galichon.com Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe pas... Librement, Niveau source possible de comparaison, il y a aussi Service-Public.fr Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il suffirait peut-être de récupérer également la variable /Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a également /Organisme@codeInsee). https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html Sinon je n'ai pas encore pris le temps de me pencher sur la mise à jour auto de ça http://www.ideeslibres.org/service-public-fr-annuaire-de-ladministration-base-de-donnees-locales-v2/ mais je peux relancer mon script manuellement si vous en avez l'utilité. Brice ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 12:53, Brice Person a écrit : Salut, Le 22/12/2013 10:02, Christophe Merlet a écrit : Le 22/12/2013 09:44, Christian Quest a écrit : Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! Ben ya la source officiel de la Poste http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Mais c'est un formulaire Web Sinon j'ai déjà constaté à quelques reprises que les infos de la poste divergeait des infos compilé par galichon.com Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe pas... Librement, Niveau source possible de comparaison, il y a aussi Service-Public.fr Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il suffirait peut-être de récupérer également la variable /Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a également /Organisme@codeInsee). https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html Sinon je n'ai pas encore pris le temps de me pencher sur la mise à jour auto de ça http://www.ideeslibres.org/service-public-fr-annuaire-de-ladministration-base-de-donnees-locales-v2/ mais je peux relancer mon script manuellement si vous en avez l'utilité. Brice Je viens de me rappeler qu'il y a aussi http://public.opendatasoft.com/explore/dataset/correspondance-code-insee-code-postal/#?tab=table sous licence ouverte PS: je me suis aussi trompé de variable, c'est /Organisme/Adresse/CodePostal ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mayotte limites adminstratives
2013/12/19 Pieren pier...@gmail.com 2013/12/19 Nicolas Croiset (VDL) ncroi...@vdl.fr: pour info, Mayotte a ouvert il y a quelques mois un portail géographique http://www.geomayotte.fr/ Comme c'est mimi, ils utilisent OpenStreetMap : http://www.geomayotte.fr/accueil/catalogue/?uuid=2e416991-7c0c-46c6-bec3-684346519b86 Si on leur demande quelque chose, pas besoin d'expliquer le projet : ils connaissent déjà ! Oui, alors la dessus faut pas trop s'emballer, la plateforme utilise 'prodige' qui se base sur l'outil geosource/geonetwork pour la gestion des fiches de metadonnees, et ce dernier utilise OSM par defaut pour afficher les bbox et la carte pour la recherche. Donc ils ne sont pas forcement au courant qu'ils utilisent OSM :) Et non philippe, ce n'est pas base sur le geoportail de l'IGN. Landry ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap : besoin de testeurs (encore)
Pas de données pour la Corse ? Le 22 décembre 2013 10:05, yvecai yve...@gmail.com a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org Merci d'avance ! Yves ___ 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] codes postaux...
Quel organisme choisir avec ta solution ? Est-on sûr que l'organisme en question compétent sur une commune (la mairie par exemple) a bien son siège dans la commune ? Ou que c'est au même endroit qu'elle y gère le courrier entrant (on peut avoir une mairie dans la commune, mais son adresse postale gérée ailleurs ; on peut aussi facilement trouver des codes Cedex pour les mairies de commune importante, et pas autant de mairies que de zones postales dans les communes découpées en plusieurs zones postales) ? Il me semble que la Poste a attribué ses zones de distribution postales comme elle le veut, et que cela n'a jamais influencé l'emplacement physique des autres services publics. Et que les communes n'ont pas nécessité non plus de recevoir le courrier à leur siège au point d'accueil du public Et que les mairies peuvent avoir aussi plusieurs lieux d'accueil (dont un dans la commune), mais pas forcément tous ses services administratifs qui peuvent être délocalisés et cogérés (par exemple dans un service commun de la communauté de communes, ou encore à la préfecture). Du coup l'adresse postale (ou les adresses postales selon les services municipaux...) peut ne pas correspondre à l'emplacement physique du siège. Les mairies peuvent aussi déménager dans la commune et garder leur code postal à la Poste... Le 22 décembre 2013 13:27, Brice Person brice.per...@zenordi.fr a écrit : Le 22/12/2013 12:53, Brice Person a écrit : Salut, Le 22/12/2013 10:02, Christophe Merlet a écrit : Le 22/12/2013 09:44, Christian Quest a écrit : Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! Ben ya la source officiel de la Poste http://www.laposte.fr/Particulier/Utiliser-nos- outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Mais c'est un formulaire Web Sinon j'ai déjà constaté à quelques reprises que les infos de la poste divergeait des infos compilé par galichon.com Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe pas... Librement, Niveau source possible de comparaison, il y a aussi Service-Public.fr Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il suffirait peut-être de récupérer également la variable /Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a également /Organisme@codeInsee). https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html Sinon je n'ai pas encore pris le temps de me pencher sur la mise à jour auto de ça http://www.ideeslibres.org/service-public-fr-annuaire-de- ladministration-base-de-donnees-locales-v2/ mais je peux relancer mon script manuellement si vous en avez l'utilité. Brice Je viens de me rappeler qu'il y a aussi http://public.opendatasoft. com/explore/dataset/correspondance-code-insee-code-postal/#?tab=tablesous licence ouverte PS: je me suis aussi trompé de variable, c'est /Organisme/Adresse/ CodePostal ___ 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] Opensnowmap : besoin de testeurs (encore)
Firefox a jour sous W7, attention, râleur en force (ceci-dit, j'ai toujours admiré ton site…) : - À l'accueil, les boutons controle, légende… sont sur deux lignes, avec l'ascenseur (c'est quoi, le mot savant ?) qui apparait. Pas très beau, pas très utilisable. - Je trouve « controles » pas très parlant, vu que c'est surtout une question de fonds de carte. - Data. Données, c'est pas parlant, en français ? - Sinon, je trouve que data et blog pourraient être situés ailleurs, comme ils sont moins lié aux fonctionnalités et renvoient vers des pages différentes. - Globalement, je trouve aussi que ça manque d'infobulles, les dessins sur les boutons ne sont pas toujours très parlant. - Je ne sais pas si l'anglais est la version de développement, si c'est le cas, il manque quelques traductions vers le Français. JB. Le 22.12.2013 10:05, yvecai a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org [1] Merci d'avance ! Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://beta.opensnowmap.org [2] 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] Opensnowmap : besoin de testeurs (encore)
C'est cool, c'est exactement le genre de retours que j'attendais. Contrôle : paramètres ? Pour le browser, ce doit être une question de zoom, il faut que je trouve comment gérer ça, en attendant fais ctrl - Noté les infos-bulle. Mais c'est encore des trads. Pour les dessins, je prends volontiers vos crobards :-) JB jb...@mailoo.org a écrit : Firefox a jour sous W7, attention, râleur en force (ceci-dit, j'ai toujours admiré ton site…) : - À l'accueil, les boutons controle, légende… sont sur deux lignes, avec l'ascenseur (c'est quoi, le mot savant ?) qui apparait. Pas très beau, pas très utilisable. - Je trouve « controles » pas très parlant, vu que c'est surtout une question de fonds de carte. - Data. Données, c'est pas parlant, en français ? - Sinon, je trouve que data et blog pourraient être situés ailleurs, comme ils sont moins lié aux fonctionnalités et renvoient vers des pages différentes. - Globalement, je trouve aussi que ça manque d'infobulles, les dessins sur les boutons ne sont pas toujours très parlant. - Je ne sais pas si l'anglais est la version de développement, si c'est le cas, il manque quelques traductions vers le Français. JB. Le 22.12.2013 10:05, yvecai a écrit : Salut à tous, Cela doit bien faire 4-5 fois que je refais le design du site. Cette fois-ci, j'ai commencé par maquetter le tout avec Inkscape. Outre le temps gagné (franchement, je conseille !), je pense que le design est plus abouti vu que j'ai réussi à le mettre en œuvre tel que je l'avais dessiné. Alors voilà, faites-moi part de vos retours pendant que je suis en vacances: http://beta.opensnowmap.org [1] Merci d'avance ! Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://beta.opensnowmap.org [2] https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Ces codes postaux proviennent de wikipédia, je les utilise déjà pour contrôle, mais je cherche une autre source que WP. Celle de services-publics.fr est intéressante. L'idéal ce sont des sources même partielles avec code INSEE, code postal, nom de commune, nom de bureau distributeur Le 22 décembre 2013 13:27, Brice Person brice.per...@zenordi.fr a écrit : Le 22/12/2013 12:53, Brice Person a écrit : Salut, Le 22/12/2013 10:02, Christophe Merlet a écrit : Le 22/12/2013 09:44, Christian Quest a écrit : Je suis en train de vérifier les codes postaux sur les communes. Un peu d'harmonisation ne ferait pas de mal car on a un mélange de addr:postcode=* et postal_code=* parfois sur la relation parfois sur le noeud place=* En combinant tout les cas, il n'en manquait qu'un peu plus de 300. J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les relations. Ne reste plus que les Côtes d'Armor... 139 CP manquants ;) Ensuite vérification globale avec une extraction des codes postaux de wikipédia pour voir où on a des différences... si vous avez d'autres sources de CP pour vérifier, je suis preneur ! Ben ya la source officiel de la Poste http://www.laposte.fr/Particulier/Utiliser-nos- outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Mais c'est un formulaire Web Sinon j'ai déjà constaté à quelques reprises que les infos de la poste divergeait des infos compilé par galichon.com Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe pas... Librement, Niveau source possible de comparaison, il y a aussi Service-Public.fr Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il suffirait peut-être de récupérer également la variable /Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a également /Organisme@codeInsee). https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html Sinon je n'ai pas encore pris le temps de me pencher sur la mise à jour auto de ça http://www.ideeslibres.org/service-public-fr-annuaire-de- ladministration-base-de-donnees-locales-v2/ mais je peux relancer mon script manuellement si vous en avez l'utilité. Brice Je viens de me rappeler qu'il y a aussi http://public.opendatasoft. com/explore/dataset/correspondance-code-insee-code-postal/#?tab=tablesous licence ouverte PS: je me suis aussi trompé de variable, c'est /Organisme/Adresse/ CodePostal ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 14:37, Christian Quest a écrit : Ces codes postaux proviennent de wikipédia, je les utilise déjà pour contrôle, mais je cherche une autre source que WP. Celle de services-publics.fr http://services-publics.fr est intéressante. L'idéal ce sont des sources même partielles avec code INSEE, code postal, nom de commune, nom de bureau distributeur Pourtant, contrôler une source WP avec elle même, ça assure du 100% de match, le graâl :-) Il y a des sources partielles, comme l'adresse des mairies de Paca : https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op mais pas exempt de Cedex, donc ménage à faire. On a aussi les 16000 bureaux de poste, bien sûr. Faute de source globale (à moins que service-public.fr le permette), on pourrait fusionner toutes les communes ayant le même CP, et voir si certains codes sont répartis sur plusieurs polygones disjoints, ce qui (hors les îles maritimes) pourrait indiquer un soupçon d'erreur ? Enfin, car je suppose que la finalité est de publier ça sur data.gouv.fr, ce serait bien de traiter le cas des communes à CP multiples, histoire de publier quelque chose d'abouti avec une vraie valeur ajoutée. Des partants pour qu'on s'y colle ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 12:42, Christophe Merlet a écrit : Le 22/12/2013 12:23, Christian Quest a écrit : Maintenant que tout les codes postaux des communes françaises sont dans OSM, que dites-vous d'harmoniser tout ça ? Il y a actuellement 2 tags utilisés sur les relations des communes: - addr:postcode - postal_code Le wiki indique que les tags addr:* sont à utiliser pour indiquer les adresses et que postal_code=* est à utiliser pour indiquer le code postal correspondant à une zone. La distinction me semble utile. Distinguer un code postal d'un... code postal, donc :-( Il semble donc logique d'utiliser postal_code=* sur les relations si l'on suit le wiki. La dernière modification du wiki est juste pour cette explication que je trouve foireuse. Le problème, c'est que dans la très grande majorité, ce sont actuellement des addr:postcode=* qui figurent sur les relations des communes françaises: - 25518+33531 addr:postcode=* sur les relations + nœuds place=* - 19+618 postal_code=* sur les relations + noeuds place=* Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.org/keys/postal_code#map http://taginfo.openstreetmap.org/keys/addr:postcode#map a quelques arguments. Je suis d'avis d'utiliser partout addr:postcode Il y a un schéma relativement complet concernant l’adressage, utilisons -le. +1 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 14:52, Vincent de Château-Thierry a écrit : Le 22/12/2013 14:37, Christian Quest a écrit : Ces codes postaux proviennent de wikipédia, je les utilise déjà pour contrôle, mais je cherche une autre source que WP. Celle de services-publics.fr http://services-publics.fr est intéressante. L'idéal ce sont des sources même partielles avec code INSEE, code postal, nom de commune, nom de bureau distributeur Pourtant, contrôler une source WP avec elle même, ça assure du 100% de match, le graâl :-) Il y a des sources partielles, comme l'adresse des mairies de Paca : https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op mais pas exempt de Cedex, donc ménage à faire. On a aussi les 16000 bureaux de poste, bien sûr. Faute de source globale (à moins que service-public.fr le permette), on pourrait fusionner toutes les communes ayant le même CP, et voir si certains codes sont répartis sur plusieurs polygones disjoints, ce qui (hors les îles maritimes) pourrait indiquer un soupçon d'erreur ? Enfin, car je suppose que la finalité est de publier ça sur data.gouv.fr, ce serait bien de traiter le cas des communes à CP multiples, histoire de publier quelque chose d'abouti avec une vraie valeur ajoutée. Des partants pour qu'on s'y colle ? vincent Avec service-public.fr, à mon avis il y a moyen d'arriver à quelque chose de bien (mais peut-être pas global), il y a les infos cedex et les types d'adresses (mais inutile à mon avis pour cet usage). Je pense qu'il suffirait d'agréger les codes postaux possibles par codes insee en excluant d'abord les cedex (avec une regex dans un grep sur le csv initial par exemple). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22 décembre 2013 15:01, Vincent de Château-Thierry v...@laposte.net a écrit : Le 22/12/2013 12:42, Christophe Merlet a écrit : Le 22/12/2013 12:23, Christian Quest a écrit : Maintenant que tout les codes postaux des communes françaises sont dans OSM, que dites-vous d'harmoniser tout ça ? Il y a actuellement 2 tags utilisés sur les relations des communes: - addr:postcode - postal_code Le wiki indique que les tags addr:* sont à utiliser pour indiquer les adresses et que postal_code=* est à utiliser pour indiquer le code postal correspondant à une zone. La distinction me semble utile. Distinguer un code postal d'un... code postal, donc :-( Visiblement je n'étais pas assez clair... addr:postcode c'est à utiliser pour chaque adresse, donc quelque chose de ponctuel et de relativement nombreux pour un code postal donné. C'est avant tout lié à un bâtiment, UNE adresse. postal_code est décrit dans le wiki pour définir la zone sur laquelle un code postal s'applique. Il semble donc logique d'utiliser postal_code=* sur les relations si l'on suit le wiki. La dernière modification du wiki est juste pour cette explication que je trouve foireuse. Le problème, c'est que dans la très grande majorité, ce sont actuellement des addr:postcode=* qui figurent sur les relations des communes françaises: - 25518+33531 addr:postcode=* sur les relations + nœuds place=* - 19+618 postal_code=* sur les relations + noeuds place=* Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.org/keys/postal_code#map http://taginfo.openstreetmap.org/keys/addr:postcode#map a quelques arguments. Bien sûr... et les chiffres aussi, mais on compare ici deux choses qui n'ont pas la même signification (cf au dessus). C'est comme comparer addr:city et le name=* sur les communes. Je suis d'avis d'utiliser partout addr:postcode Il y a un schéma relativement complet concernant l’adressage, utilisons -le. +1 Je trouve aussi que d'utiliser un tag dans le même namespace est plus cohérent... c'est pour ça que je n'ai pas d'avis tranché pour l'un ou l'autre des solutions sur les relations. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 15:08, Brice Person a écrit : Le 22/12/2013 14:52, Vincent de Château-Thierry a écrit : Le 22/12/2013 14:37, Christian Quest a écrit : Ces codes postaux proviennent de wikipédia, je les utilise déjà pour contrôle, mais je cherche une autre source que WP. Celle de services-publics.fr http://services-publics.fr est intéressante. L'idéal ce sont des sources même partielles avec code INSEE, code postal, nom de commune, nom de bureau distributeur Pourtant, contrôler une source WP avec elle même, ça assure du 100% de match, le graâl :-) Il y a des sources partielles, comme l'adresse des mairies de Paca : https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op mais pas exempt de Cedex, donc ménage à faire. On a aussi les 16000 bureaux de poste, bien sûr. Faute de source globale (à moins que service-public.fr le permette), on pourrait fusionner toutes les communes ayant le même CP, et voir si certains codes sont répartis sur plusieurs polygones disjoints, ce qui (hors les îles maritimes) pourrait indiquer un soupçon d'erreur ? Enfin, car je suppose que la finalité est de publier ça sur data.gouv.fr, ce serait bien de traiter le cas des communes à CP multiples, histoire de publier quelque chose d'abouti avec une vraie valeur ajoutée. Des partants pour qu'on s'y colle ? vincent Avec service-public.fr, à mon avis il y a moyen d'arriver à quelque chose de bien (mais peut-être pas global), il y a les infos cedex et les types d'adresses (mais inutile à mon avis pour cet usage). Je pense qu'il suffirait d'agréger les codes postaux possibles par codes insee en excluant d'abord les cedex (avec une regex dans un grep sur le csv initial par exemple). Je viens de tester avec ma version pas à jour, ça me donne 37 168 codes postaux différents sur 59 348 organismes et effectivement pas mal de codes insee qui partagent le même code postal. Du coup ça me motive à mettre à jour le csv :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22 décembre 2013 14:52, Vincent de Château-Thierry v...@laposte.net a écrit : Le 22/12/2013 14:37, Christian Quest a écrit : Ces codes postaux proviennent de wikipédia, je les utilise déjà pour contrôle, mais je cherche une autre source que WP. Celle de services-publics.fr http://services-publics.fr est intéressante. L'idéal ce sont des sources même partielles avec code INSEE, code postal, nom de commune, nom de bureau distributeur Pourtant, contrôler une source WP avec elle même, ça assure du 100% de match, le graâl :-) Il y a des sources partielles, comme l'adresse des mairies de Paca : https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op mais pas exempt de Cedex, donc ménage à faire. On a aussi les 16000 bureaux de poste, bien sûr. Oui, j'y pensais justement... les codes postaux sont en fait liés à un bureau de poste, donc autant repartir de là. Faute de source globale (à moins que service-public.fr le permette), on pourrait fusionner toutes les communes ayant le même CP, et voir si certains codes sont répartis sur plusieurs polygones disjoints, ce qui (hors les îles maritimes) pourrait indiquer un soupçon d'erreur ? Je sort le shapefile d'ici quelques minutes... Enfin, car je suppose que la finalité est de publier ça sur data.gouv.fr, ce serait bien de traiter le cas des communes à CP multiples, histoire de publier quelque chose d'abouti avec une vraie valeur ajoutée. Oui, gagné pour data.gouv.fr T'inquiète pas pour les CP multiples, je connais bien le problème étant dans un de ces cas particuliers, avec un plus un nombre de bureau distributeur qui n'a pas de rapport avec le nom de la commune ! Des partants pour qu'on s'y colle ? Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 15:49, Christian Quest a écrit : Visiblement je n'étais pas assez clair... addr:postcode c'est à utiliser pour chaque adresse, donc quelque chose de ponctuel et de relativement nombreux pour un code postal donné. C'est avant tout lié à un bâtiment, UNE adresse. postal_code est décrit dans le wiki pour définir la zone sur laquelle un code postal s'applique. Si, j'avais bien compris le distingo que tu proposes. Et c'est bien en réponse à ça que je faisais la :-( En gros on est en train de dire que pour une même notion (le code postal), il faudrait selon l'envergure de l'objet auquel elle s'applique, utiliser 2 balises distinctes. C'est faire compliqué pour le plaisir, définitivement, vu qu'on parle bien toujours du code postal. Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.__org/keys/postal_code#map http://taginfo.openstreetmap.org/keys/postal_code#map http://taginfo.openstreetmap.__org/keys/addr:postcode#map http://taginfo.openstreetmap.org/keys/addr:postcode#map a quelques arguments. Bien sûr... et les chiffres aussi, mais on compare ici deux choses qui n'ont pas la même signification (cf au dessus). La même signification ? Oui justement. Se baser sur l'envergure (ville vs immeuble) pour différencier les balises, ça reviendrait à dire pour les routes : le tag highway=* est à utiliser pour les grandes routes, mais pour les chemins locaux, utilisons le tag road=* (ou n'importe quel autre), alors qu'on parle de routes dans les 2 cas. À part embrouiller aussi bien les contributeurs que les utilisateurs, je ne vois pas trop... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 16:16, Vincent de Château-Thierry a écrit : La même signification ? Oui justement. Se baser sur l'envergure (ville vs immeuble) zone vs adresse pour différencier les balises, ça reviendrait à dire pour les routes : le tag highway=* est à utiliser pour les grandes routes, mais pour les chemins locaux, utilisons le tag road=* (ou n'importe quel autre), alors qu'on parle de routes dans les 2 cas. À part embrouiller aussi bien les contributeurs que les utilisateurs, je ne vois pas trop... La comparaison porterait plus sur le tag maxspeed. En agglomération (zone) le maxspeed par défaut est 50, par contre pour telle route il peut être 30, 70... vincent -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 15:52, Christian Quest a écrit : Oui, gagné pour data.gouv.fr http://data.gouv.fr T'inquiète pas pour les CP multiples, je connais bien le problème étant dans un de ces cas particuliers, avec un plus un nombre de bureau distributeur qui n'a pas de rapport avec le nom de la commune ! Des partants pour qu'on s'y colle ? Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 Une liste intéressante = 1% des communes au global. Il y a à la fois des différences de CP pour une commune avec 1 seul CP, et des différences liées à l'existence de CPs multiples pour une commune. Dans le premier cas, c'est de la pâte à MapCraft pour se répartir la révision (je le lancerai ce soir/demain si personne d'ici là). Le hic plus important, c'est pour les communes pluri-distribuées : comment trouver une source pour savoir rue par rue voire n° par n° où passe la limite de distribution ? Sur le site de La Poste, la page qui permet de tester à l'adresse est ici : http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Pas pratique du tout pour tâtonner de rue en rue. Resterait la piste OpenData, ville par ville ? Mulhouse récemment proposait ses limites postales, il me semble. Mais sans source globale, ça risque d'être un peu long à constituer... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Tu peux faire cuire la pâte à MapCraft ! J'avais un peu utilisé cet outil pour vérifier mon découpage 94100/94210. Pour l'opendata, la Poste s'y ouvre timidement... on a eu en première vague les bureaux de poste, puis dernièrement une vaguelette avec les boites aux lettre de Paris, la CU de Bordeaux et le 06... en attendant peut être mieux en janvier (il y a un évènement opendata/La Poste auquel je me suis inscrit). http://legroupe.laposte.fr/Actualite/Le-Groupe-La-Poste-partenaire-du-concours-Dataconnexions Le 22 décembre 2013 16:37, Vincent de Château-Thierry v...@laposte.net a écrit : Le 22/12/2013 15:52, Christian Quest a écrit : Oui, gagné pour data.gouv.fr http://data.gouv.fr T'inquiète pas pour les CP multiples, je connais bien le problème étant dans un de ces cas particuliers, avec un plus un nombre de bureau distributeur qui n'a pas de rapport avec le nom de la commune ! Des partants pour qu'on s'y colle ? Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 Une liste intéressante = 1% des communes au global. Il y a à la fois des différences de CP pour une commune avec 1 seul CP, et des différences liées à l'existence de CPs multiples pour une commune. Dans le premier cas, c'est de la pâte à MapCraft pour se répartir la révision (je le lancerai ce soir/demain si personne d'ici là). Le hic plus important, c'est pour les communes pluri-distribuées : comment trouver une source pour savoir rue par rue voire n° par n° où passe la limite de distribution ? Sur le site de La Poste, la page qui permet de tester à l'adresse est ici : http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et- documents/Trouvez-un-code-postal Pas pratique du tout pour tâtonner de rue en rue. Resterait la piste OpenData, ville par ville ? Mulhouse récemment proposait ses limites postales, il me semble. Mais sans source globale, ça risque d'être un peu long à constituer... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le dimanche 22 décembre 2013 15:01:17, Vincent de Château-Thierry a écrit : Je suis d'avis d'utiliser partout addr:postcode Il y a un schéma relativement complet concernant l’adressage, utilisons -le. +1 +1 -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 16:37, Vincent de Château-Thierry a écrit : Le 22/12/2013 15:52, Christian Quest a écrit : Oui, gagné pour data.gouv.fr http://data.gouv.fr T'inquiète pas pour les CP multiples, je connais bien le problème étant dans un de ces cas particuliers, avec un plus un nombre de bureau distributeur qui n'a pas de rapport avec le nom de la commune ! Des partants pour qu'on s'y colle ? Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 Une liste intéressante = 1% des communes au global. Il y a à la fois des différences de CP pour une commune avec 1 seul CP, et des différences liées à l'existence de CPs multiples pour une commune. Dans le premier cas, c'est de la pâte à MapCraft pour se répartir la révision (je le lancerai ce soir/demain si personne d'ici là). Je viens de finir l'Aquitaine... Le hic plus important, c'est pour les communes pluri-distribuées : comment trouver une source pour savoir rue par rue voire n° par n° où passe la limite de distribution ? Sur le site de La Poste, la page qui permet de tester à l'adresse est ici : http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal Pas pratique du tout pour tâtonner de rue en rue. Resterait la piste OpenData, ville par ville ? Mulhouse récemment proposait ses limites postales, il me semble. Mais sans source globale, ça risque d'être un peu long à constituer... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 15:52, Christian Quest a écrit : Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 Le Doubs (25) et la Haute-Saône (70) sont corrigés. C'est plus compliqué pour le Jura. Tout des communes avec 2 CP. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 15:52, Christian Quest a écrit : Oui, j'y pensais justement... les codes postaux sont en fait liés à un bureau de poste, donc autant repartir de là. Bonsoir, Faux! Le CP est lié à un bureau distributeur. Le bureau distributeurs n'est pas lié à un bureau de poste (accueil du public). Toutefois depuis la mise en place des CP dans les années 1970 de très grosses modifications ont eu lieu sur le réseau de distribution. Désormais plusieurs CP peuvent se retrouver sur un bureau de distribution (38200, 38121, 38138, 38670 sont en une seule plate-forme de distribution) Certaines communes peuvent se trouver aussi sur 2 plate-formes de distribution (Reventin-Vaugris est sur 38121 et 38370) Pour Paris il n'y a pas de soucis 1 CP (normal)=1 arrondissement, Il n'y a pas, de fait, de 75000 mais directement 75001. Les correspondances 75000 sont acheminées sur 75001 d'office pour être acheminées au bon bureau. Pour les cedex il y a une manip à connaître: 75 7 21 on regarde si les deux derniers chiffres sont inférieurs ou supérieurs à 43 devient 1 et devient 2. 7 est multiplié par 2 On additionne les deux chiffres 75721 donne le 15° (21 est inférieur à 43 donc 1 + 7*2=14 donne 15) Il conviendra de faire attention car les 1-2-3 et 4 sont rassemblés sur une seule plate-forme de distribution à Paris-Louvre (rue du Louvre, le bureau ouvert 24/24-7/7) Il y a une série d'exeptions: 700 Services de l'état dans le 7° 800 Services de l'état dans le 8° (si ma mémoire ne me trahit pas quant à son existence) 998 Service postal militaire (je ne sais plus où il est physiquement xxx probablement d'autres que je n'ai plus en mémoire. Pour les grandes communes Lyon là aussi 1 CP = 1 arrondissement Marseille il faut se renseigner car je ne connais pas Pour les autres communes à distributions décentralisées il faut se renseigner au coup par coup car c'est le hasard des décisions administratives internes à La Poste et là il n'y a pas de règle. ET parfois des modifications se font jours sans réel avertissement des populations concernées. Tous les centres financiers (CCP et CNE) de La Poste sont en 900 quel que soit leur département y compris si plusieurs sites géographiques. Le seul qui peut poser problème quant à sa localisation est La Source (SCE) qui est situé à Fleury les Aubrays dans la banlieue d'Orléans. Tous les autres sont lié à une commune. Ces codes n'ont plus d'équivalence géographique depuis longtemps. En effet vous pouvez ouvrir un compte dans le centre de votre choix même si l'agent va vous proposer en priorité celui de la zone où se trouve son bureau (logique). Seuls les parisiens ont deux possibilités aléatoires en fonction des disponibilités (Paris et La Source). Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 12:23, Christian Quest a écrit : Maintenant que tout les codes postaux des communes françaises sont dans OSM, que dites-vous d'harmoniser tout ça ? Il y a actuellement 2 tags utilisés sur les relations des communes: - addr:postcode - postal_code Le wiki indique que les tags addr:* sont à utiliser pour indiquer les adresses et que postal_code=* est à utiliser pour indiquer le code postal correspondant à une zone. La distinction me semble utile. Il semble donc logique d'utiliser postal_code=* sur les relations si l'on suit le wiki. Le problème, c'est que dans la très grande majorité, ce sont actuellement des addr:postcode=* qui figurent sur les relations des communes françaises: - 25518+33531 addr:postcode=* sur les relations + nœuds place=* - 19+618 postal_code=* sur les relations + noeuds place=* Au niveau international, postal_code semble relativement utilisé: http://taginfo.openstreetmap.org/keys/postal_code#map Je serais bien tenté de passer en postal_code les addr:postcode=* qu'on a actuellement sur les relations des communes pour être cohérent à l'international et pour bien distinguer une zone de code postal avec le code postal d'une adresse, mais n'y a-t-il pas de risque pour les réutilisateurs hexagonaux qui se sont (faussement) basés sur addr:postcode=* ? Qu'en dites-vous ? Re bonsoir, Nous voila devant la problématique géniale. Le code postal est une relation en lui-même puisqu'il couvre une zone géographique non collée à d'autre entité (la commune est bien une relation, nous avons donc le même cas). Inversement des entités peuvent se raccrocher à un code postal. Une adresse se rattache à un code postal (comme à une commune) mais jamais l'inverse. Il faut aussi qu'un code postal puisse en chevaucher un autre, en effet certaines communes ont 2 codes pour exactement les mêmes adresses physiques mais un seul établissement distributeur physique. Ce sont souvent des lieux sis en montagne et dont la distribution est faite par le service postal d'un autre département. On peut retrouver le même cas avec les enclaves, ou exclaves, selon l'endroit d'analyse. Ceci pour alimenter votre réflexion. Voir aussi ma réponse sur le fil voisin qui doit aussi servir à cette réflexion. Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 19:28, Yannick VOYEAUD a écrit : Il faut aussi qu'un code postal puisse en chevaucher un autre, en effet certaines communes ont 2 codes pour exactement les mêmes adresses physiques mais un seul établissement distributeur physique. Ce sont souvent des lieux sis en montagne et dont la distribution est faite par le service postal d'un autre département. Ça m'étonne, ça : deux codes postaux pour un même emplacement physique. Sur le site de la Poste, quand deux codes sont possibles pour une commune, la page demande une information sur la rue concernée pour lever le doute : codes différents = rues différentes On doit donc pouvoir faire des zones ne se recouvrant pas. Je n'ai pas fait pour le Jura parce que je ne connais pas les limites exactes (elles se devinent parfois), et que je ne sais pas comment tagguer la relation, si d'autres tags que addr:postcode (j'aime pourtant mieux code_postal pour désigner une zone) sont nécessaire... Et sur les ways spécifiques ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Harmoniser les codes postaux - postal_code=*
Le 22/12/2013 20:03, Vincent Pottier a écrit : Le 22/12/2013 19:28, Yannick VOYEAUD a écrit : Il faut aussi qu'un code postal puisse en chevaucher un autre, en effet certaines communes ont 2 codes pour exactement les mêmes adresses physiques mais un seul établissement distributeur physique. Ce sont souvent des lieux sis en montagne et dont la distribution est faite par le service postal d'un autre département. Ça m'étonne, ça : deux codes postaux pour un même emplacement physique. Sur le site de la Poste, quand deux codes sont possibles pour une commune, la page demande une information sur la rue concernée pour lever le doute : codes différents = rues différentes On doit donc pouvoir faire des zones ne se recouvrant pas. Je n'ai pas fait pour le Jura parce que je ne connais pas les limites exactes (elles se devinent parfois), et que je ne sais pas comment tagguer la relation, si d'autres tags que addr:postcode Dans ces cas, il faudra rajouter addr:codepost dans la relation associatedStreet des numéros d'adresses. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux...
Le 22/12/2013 18:27, Christophe Merlet a écrit : Le 22/12/2013 16:37, Vincent de Château-Thierry a écrit : Le 22/12/2013 15:52, Christian Quest a écrit : Oui, gagné pour data.gouv.fr http://data.gouv.fr T'inquiète pas pour les CP multiples, je connais bien le problème étant dans un de ces cas particuliers, avec un plus un nombre de bureau distributeur qui n'a pas de rapport avec le nom de la commune ! Des partants pour qu'on s'y colle ? Si y'a des volontaires, voici une liste de CP qui ne collent pas entre OSM et wikipédia: https://gist.github.com/cquest/234497eb7cd2366b5726 Une liste intéressante = 1% des communes au global. Il y a à la fois des différences de CP pour une commune avec 1 seul CP, et des différences liées à l'existence de CPs multiples pour une commune. Dans le premier cas, c'est de la pâte à MapCraft pour se répartir la révision (je le lancerai ce soir/demain si personne d'ici là). Je viens de finir l'Aquitaine... Et Midi-Pyrénées Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux... (en dessert)
Le 22/12/2013 20:16, Christophe Merlet a écrit : Le 22/12/2013 18:27, Christophe Merlet a écrit : Le 22/12/2013 16:37, Vincent de Château-Thierry a écrit : Une liste intéressante = 1% des communes au global. Il y a à la fois des différences de CP pour une commune avec 1 seul CP, et des différences liées à l'existence de CPs multiples pour une commune. Dans le premier cas, c'est de la pâte à MapCraft pour se répartir la révision (je le lancerai ce soir/demain si personne d'ici là). Je viens de finir l'Aquitaine... Et Midi-Pyrénées Avant que Vincent et Christophe ne mangent tout :-) voici de quoi picorer les codes postaux à vérifier voire corriger. Pour rappel, leur sélection vient d'une différence constatée entre WP et OSM. La géométrie des parts n'est pas le contour des communes (sinon le fichier était trop gros pour Mapcraft). Atout carreau :-) http://mapcraft.nanodesu.ru/pie/350 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux... (en dessert)
Parmi les différence on voit des confusions dans Wikipédia entre les codes postaux et les codes INSEE... Attention, tout n'est pas bon sur Wikipédia non plus, les corrections sont à faire des deux côtés. Le 22 décembre 2013 22:39, Vincent de Château-Thierry v...@laposte.net a écrit : Avant que Vincent et Christophe ne mangent tout :-) voici de quoi picorer les codes postaux à vérifier voire corriger. Pour rappel, leur sélection vient d'une différence constatée entre WP et OSM. La géométrie des parts n'est pas le contour des communes (sinon le fichier était trop gros pour Mapcraft). Atout carreau :-) http://mapcraft.nanodesu.ru/pie/350 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux... (en dessert)
Le 22/12/2013 23:09, Philippe Verdy a écrit : Parmi les différence on voit des confusions dans Wikipédia entre les codes postaux et les codes INSEE... Attention, tout n'est pas bon sur Wikipédia non plus, les corrections sont à faire des deux côtés. Philippe, si tu pouvais éviter de valider des nœuds dans le mapcraft que tu ne corriges même pas. Ex Rennes. Merci Le 22 décembre 2013 22:39, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Avant que Vincent et Christophe ne mangent tout :-) voici de quoi picorer les codes postaux à vérifier voire corriger. Pour rappel, leur sélection vient d'une différence constatée entre WP et OSM. La géométrie des parts n'est pas le contour des communes (sinon le fichier était trop gros pour Mapcraft). Atout carreau :-) http://mapcraft.nanodesu.ru/__pie/350 http://mapcraft.nanodesu.ru/pie/350 Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux... (en dessert)
Justement j'en ai discuté (ici et dans Mapcraft) et je n'ai pas vu d'anomalie du tout. Ou alors je ne sais pas du tout ce que tu veux tester. Est-ce le fait que Rennes a plusieurs codes postaux, cela ne le semble pas du tout une anomalie. Personne n'a répondu à la demande. Le 23 décembre 2013 00:46, Christophe Merlet red...@redfoxcenter.org a écrit : Le 22/12/2013 23:09, Philippe Verdy a écrit : Parmi les différence on voit des confusions dans Wikipédia entre les codes postaux et les codes INSEE... Attention, tout n'est pas bon sur Wikipédia non plus, les corrections sont à faire des deux côtés. Philippe, si tu pouvais éviter de valider des nœuds dans le mapcraft que tu ne corriges même pas. Ex Rennes. Merci Le 22 décembre 2013 22:39, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Avant que Vincent et Christophe ne mangent tout :-) voici de quoi picorer les codes postaux à vérifier voire corriger. Pour rappel, leur sélection vient d'une différence constatée entre WP et OSM. La géométrie des parts n'est pas le contour des communes (sinon le fichier était trop gros pour Mapcraft). Atout carreau :-) http://mapcraft.nanodesu.ru/__pie/350 http://mapcraft.nanodesu.ru/pie/350 Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes postaux... (en dessert)
En plus toi même ne répond pas non plus, au lieu de faire un reproche ici, tu peux dire ce qui ne va pas ? Je ne vois qu'ne seule chose : l'article Wikipédia donne 3 codes postaux seulement dans son infobox, et omet 35100 qui existe pourtant bel et bien à Rennes (en plus de 35000, 35200 et 35700). Et ce ne sont pas des Cedex. Il est possible qu'il y en ait d'autres mais pour moi ce sont des Cedex ou codes spéciaux de regroupements, ou des codes de l'armée (qui ne sont pas réellement géolocalisés, la poste remet juste à un endroit le courrier qui est acheminé par le service postal interne des armées). Le 23 décembre 2013 06:43, Philippe Verdy verd...@wanadoo.fr a écrit : Justement j'en ai discuté (ici et dans Mapcraft) et je n'ai pas vu d'anomalie du tout. Ou alors je ne sais pas du tout ce que tu veux tester. Est-ce le fait que Rennes a plusieurs codes postaux, cela ne le semble pas du tout une anomalie. Personne n'a répondu à la demande. Le 23 décembre 2013 00:46, Christophe Merlet red...@redfoxcenter.org a écrit : Le 22/12/2013 23:09, Philippe Verdy a écrit : Parmi les différence on voit des confusions dans Wikipédia entre les codes postaux et les codes INSEE... Attention, tout n'est pas bon sur Wikipédia non plus, les corrections sont à faire des deux côtés. Philippe, si tu pouvais éviter de valider des nœuds dans le mapcraft que tu ne corriges même pas. Ex Rennes. Merci Le 22 décembre 2013 22:39, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Avant que Vincent et Christophe ne mangent tout :-) voici de quoi picorer les codes postaux à vérifier voire corriger. Pour rappel, leur sélection vient d'une différence constatée entre WP et OSM. La géométrie des parts n'est pas le contour des communes (sinon le fichier était trop gros pour Mapcraft). Atout carreau :-) http://mapcraft.nanodesu.ru/__pie/350 http://mapcraft.nanodesu.ru/pie/350 Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] OpenSnowMap
こん＊＊は。下り専門です。 OpenSnowMap のYvesさんに、日本語の対応をしてもらいました。 ・タイルのマルチバイト対応 (support for 'unifont' as a fallback if DejaVu fails) ・メッセージファイルの日本語化 私はその名の通りダウンヒル専門でクロスカントリーは一度もやったことがありません。 誤訳がありましたら訂正お願いします。 日本のコースはまだほとんどマッピングされていません。 例はニセコです。 http://www.opensnowmap.org/index.html?zoom=14lat=42.87458lon=140.68697layers=marker=false 右下の指がiを押しているアイコンを選んでから、 地図上のコースの任意の２点を選ぶと標高差（斜度）のグラフが見られます。 ウインタースポーツをされる方はいよいよシーズンインですね。 GPSロガーもゲレンデに連れて行ってマッピングを楽しんでください。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] GPSログ共有アプリ「轍」のご紹介
下り専門です。 そうそう、重要なことを書いてませんでした。 openstreetmap.org のタイルは利用制限があるので、 osm.jp のタイルを使ってもらうようにしています。 jpのほうは自由に使えるという認識ですが問題ないですよね？ 2013年12月15日 10:59 Satoshi IIDA nyamp...@gmail.com: いいだです。 こちらMac環境なので利用ができないのですが、面白そうなアプリですね。 GPXのログ整形機能(始点と終点部分を消す、超長距離用の間引く)とかも便利そうです。 長距離のバス路線や、東京などの「◯◯通り」を描くときにも重宝？ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSM地図に手書きメモがかけるiPhoneアプリOSM sketch
On Fri, Dec 20, 2013 at 11:19:08PM +0900, ribbon wrote: https://itunes.apple.com/jp/app/osm-sketch/id777144672?mt=8 OSM sketchと言う名で先週からapp storeに公開されてます。 OSMの地図の上に手書きが出来るアプリです。 それ自体では編集は出来ませんが、 書いた線をGPXに変換してOSMにアップロード出来ますので PCのエディタに表示出来ます。 Walking paperをスマホに入れたイメージです。 入れてみようと思ったのですが、iOS7以上指定なので 入りませんでした. iPad3をiOS7にして入れてみました。 確かに、こういうのがあると、便利ですね。 ただ、1つ気になることが。 右上に出ている1X、2X表示ですが、iPadデフォルトでは1Xで、 ここをクリックすると2Xになります。が、2Xになると画面が 半分になってしまいます。これは、表示が逆ではないでしょうか。 ribbon ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OpenSnowMap
ども、三浦です。 On 2013年12月22日 18:56, 下り専門 wrote: 日本のコースはまだほとんどマッピングされていません。 例はニセコです。 http://www.opensnowmap.org/index.html?zoom=14lat=42.87458lon=140.68697layers=marker=false 右下の指がiを押しているアイコンを選んでから、 地図上のコースの任意の２点を選ぶと標高差（斜度）のグラフが見られます。 ウインタースポーツをされる方はいよいよシーズンインですね。 GPSロガーもゲレンデに連れて行ってマッピングを楽しんでください。 そうですね、蔵王も、わたしが数年前にいれた一部ゲレンデだけですね。 http://www.opensnowmap.org/index.html?zoom=14lat=42.87458lon=140.68697layers=marker=false モチベーションが出そうです。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] GPSログ共有アプリ「轍」のご紹介
三浦です。 On 2013年12月22日 19:00, 下り専門 wrote: 下り専門です。 そうそう、重要なことを書いてませんでした。 openstreetmap.org http://openstreetmap.org のタイルは利用制限があるので、 osm.jp http://osm.jp のタイルを使ってもらうようにしています。 jpのほうは自由に使えるという認識ですが問題ないですよね？ まだ、規約を整備できていない、という意味では、これから問題になります。 今のところ、リソースに余裕があるので、不都合にはなっていませんが。 osm.jpのサイトの方も、openstreetmap.org http://openstreetmap.org のタイルのアジアでの 配信拠点として整備したいと考えており、同等の規約にしたいと 考えています。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-GB] Warning: Freemap server upgrade tomorrow 19/12/13
To update on this: some unforeseen problems occurred with the upgrade, possibly because this is about the 6th OS upgrade that I've done over the lifetime of the server and little errors have mounted up. So, I've done a complete wipe and re-install of the VM. Due to it being nearly Christmas, however, I'm not that confident about being able to reinstall freemap before Christmas, it might be Boxing Day or even the 27th. Further update: Freemap itself is now back up. However the rendering will initially be very slow as the caches (OSM and contour) need to be regenerated. Mountainous areas are likely to be initially particularly slow due to the large number of contours. FixMyPaths and opentrailview are still not up but should be soon. Nick___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Warning: Freemap server upgrade tomorrow 19/12/13
- Further update: Freemap itself is now back up. However the rendering will initially be very slow as the caches (OSM and contour) need to be regenerated. Mountainous areas are likely to be initially particularly slow due to the large number of contours. FixMyPaths and opentrailview are still not up but should be soon. All sites now back up (not *thoroughly* tested though). Apologies for the downtime. Hopefully I should be able to move to a faster VM (provided by Bytemark still) soon which should result in performance increases, and may permit extension of Freemap coverage to Scotland. Nick ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Same thing that I did with OSM's I 35;I 80 around Des Moines, Iowa, correcting it to I 80;I 35 a few months ago. The exit numbers and mileposts confirm that this route has always been seen as I 80 by IADOT and Iowa State Patrol, since its first stretches were opened in 1958-59. http://www.iowadot.gov/50thpages/pdf/interstatemap.pdf This is the same 12-month period in which my dad took me for a drive on Britain's first motorway, the M6 Preston Bypass, on the week that it opened in 1959. I was 8 years old and already knew that I would build motorways. Later Sir James Drake (the project engineer) who was knighted for his motorway building, became my top boss at Lancashire County Council and sponsored my application to qualify as a Chartered Engineer. I remember him shaking my hand at the County Surveyor's annual dinner in 1973. Castle Rock has worked continuously with IADOT since 1985. When we first set up Iowa's Condition Acquisition and Reporting System (CARS) in 1998, we had treated the common section as I 35 (assuming a highest system, lowest number rule), and Iowa DOT staff asked us to correct this to I 80. It remains I 80 in Iowa's CARS system to this day. We use it all across the country as an example of a rule exception in discussions with other states. I 80 is the principal (i.e., first posted) Interstate route on the common section of these two roads. James and I seem to agree that such routes should be listed first in OSM's way ref tags in order to show their special significance. I don't think that this needs to be in any way controversial. It seems to me common sense that OSM should accurately reflect the road's signing details. Posting roads with their Highest system, lowest number route first is a good first approximation for armchair mapping, but it cannot be used to overrule facts on the ground. Peter Davies Castle Rock Associates Portland, Oregon On Sat, Dec 21, 2013 at 11:33 PM, James Mast rickmastfa...@hotmail.comwrote: I know awhile back I updated the ref tag on the short segment of I-77 that has I-74 cosigned with it from ref=I 74;I 77 to ref=I 77;I 74 because along that segment, they are using I-77's mile markers. Plus it helps to know that I-77 was there long before the two I-74 signs (one NB and one SB) were added along it. So, at least when it comes to Interstates with 2 or more Interstates posted on a segment, you should always put the one that the mile markers/exit numbers are based off of first in the way ref tag. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Peter, Yes, Magnificent Mile. It's been a few years! I don't have much argument with most of what you say. I was reacting to what I perceived as comments from some that what the locals call it should get priority with regards shields. It should be whatever the DOT has designated the road as (see the mile markers when installed). However there are many MAJOR roads with dual or more routes on them. A significant mid-west US example is I-80/I-90 from Elyria, OH to Gary, IN. For OSM to display only one of those route numbers in its shields is not, in my opinion, user friendly for map readers. And as I noted, it appears there is a problem with OSM and dual/multiple route tags in at least some areas: no shields show for many miles where the dual routes exist. Yes the MUTCD is a guide to what to hang on a sign post or overhead gantry rather than a mapper's guide, but the use of multiple route signs on a single pole tells you that the DOTs want us to know all the route numbers of a given stretch of pavement. The MapQuest Open layer of OSM does the same and for me at least, this does not represent shield clutter. Kerry From: Peter Davies [mailto:peter.dav...@crc-corp.com] Sent: Sunday, December 22, 2013 2:53 PM To: Kerry Irons Cc: Tod Fitch; Martijn van Exel; OSM US Talk; Richard Welty; Eric Fischer Subject: Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept Kerry, Your reference is to The Magnificent Mile, a hyped up name for Michigan Avenue, Chicago's main shopping street. I happen to be sitting on a plane to Chicago right now and the lady sitting next to me got your meaning immediately. Check out http://www.openstreetmap.org/node/153654226 You say that map users want to see all the route numbers on a given piece of pavement, not just the ... principal route. Yet there are many different types of map user, each with different needs and preferences. I had said We need a way of capturing [the principal route designator] in OSM for use in nav systems and info systems, as well as (perhaps) for ridding simple maps of route shield clutter. Note my (perhaps) and simple maps. I would never suggest that OSM mappers want to be rid of what I risked calling route shield clutter. But my job is to design map-based info systems for use by as many people as possible, and this experience tells me that multiple route designators tend to confuse the average user. My plea is that mappers ensure that the principal route designation (which every numbered highway has, at least in the eyes of police and DOTs) comes first in the way ref tag, so that simple maps, nav systems and info systems can be created that say it as briefly as possible. That way, you can have your everything maps and I can have my relatively simple info systems for ordinary folks to use. As a professional traffic engineer I know MUTCD moderately well. The Feds and AASHTO do a good job of imposing some degree of consistency on the 50 banana republics (sorry, the US states). ;) But MUTCD is not written as a mapping tool, nor as a design document for nav systems or traffic info systems. It's a useful guide to what we traffic engineers are supposed to hang on poles and gantries. In OSM, the community decides what to map, and my hope is to influence mappers to meet the diverse needs of many different user groups. Later today I'll be picking up my rental car from O'Hare and (over the holiday) driving the Kennedy, the Eden, and the Dan Ryan, etc. Like you, I'm a relative stranger to Chicago, and I'd prefer to know them as I-90 and I-94. This is why we (if Castle Rock were the Illinois 511 contractor) would reference a crash on the Dan Ryan as On I-90 (Dan Ryan Expressway) between Exit 53 (Canalport Avenue) and Exit 52 (Roosevelt Road) look out for a crash ... We try to satisfy both the locals and the visitors. Chicago's radio stations have different goals. But if I didn't mention Dan Ryan, many of the locals would say I-90? What is that? It happens that Chicago's freeways are not cluttered with rubbish numbers (thank you Shawn Quinn; not my words). Great job, I-DOT! US 41 has stayed on Lakeshore Drive, where it belongs. Kerry, our aims are not incompatible. I'm happy to defend the way ref tags too. It had been suggested that we might only need relation ref tags. It is true that there is much duplication. My point is that way ref tags tell us the priority order of the shields, and that we can get this no other way. Peter On Sun, Dec 22, 2013 at 7:19 AM, Kerry Irons irons54vor...@gmail.com wrote: Peter, The Miracle Mile is probably an anachronistic reference, but I believe it is a reference for a section of Chicago's Lake Shore Drive (also US 41). Other towns have used this reference to their business district. Note the reference in Billy Joel's It's Still Rock and
Re: [Talk-us] South Carolina State Highways - primary overload
On Tue, Dec 10, 2013 at 6:25 PM, Martijn van Exel mart...@openstreetmap.uswrote: I think discussion can only be useful if and when we have a common understanding of what 'trunk', 'primary', 'secondary' etc. mean to us. I don't think we're anywhere close to that, looking at the various and partly mutually contradictory wiki pages on the topic: I think this part of the tagging scheme that is the most puzzling issue for US mappers. In the Phoenix area, http://www.openstreetmap.org/#map=11/33.5683/-112.0901, I've used primary as a way of showing travelers what is the best way to get through all of our mountain preserve areas. Since the traffic has to funnel through these passages the amount of traffic that these roads has to handle probably lines up with what a primary road should be. I use residential for 0 to 25 mph residential roads. That tag seems obvious. I use tertiary for 30 to 35 mph roads. I see most of these types of roads as connecting residential subdivisions. These roads tend to have bike lanes too. I also see dashed yellow lines or two solid yellow lines as another indication of changing the road to tertiary in mostly residential areas. I use secondary for 40 to 45 mph roads. The roads that I have marked as primary are any where from 35 mph to 50 mph. I use motorway for the major concrete highways. This gives me a plan that I can follow with some consistency even if I cannot say that it is the correct thing to do. I ignore JOSM validation on this question because there is no highway reference for tertiary, secondary, and primary in most cases where I have used the tags. However, leaving a more than 25 mph road as residential seems like the wrong thing to do. I hope this helps, Greg ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
