Re: [Talk-hr] Biciklizam u ZG
Oprosti što se tek sad javljam. Evo, ucrtao sam stazu, makar samo do prvog križanja (jer znakovi vrijede do prvog križanja) a to križanje je na pola Mamićevog kompleksa. Malo sam gledao tvoju fotografiju, i zapravo je očito što se desilo. Zamišljena je biciklistička staza, ali onda je Erste banka zaželjela drive-in bankomat. Pitam se tko je dobio prednost, infrastruktura za bicikliste, ili bankomat za ljude kojima je teško prošetati par metara. I zbog tog drive-in bankomata je postalo nemoguće ucrtati stazu. Tako je ostao samo znak :) I nisam koristio pedestrian, pedestrian su ulice koje su pješačke zone. Ovo je pločnik, dakle: highway=path + bicycle=designated + foot=designated + segregated=no + oneway=yes Janko Dana 27. travnja 2012. 13:01 Hynek Suchy suc...@gmail.com je napisao/la: Bok Janko! Staza koja ide od rotora (početak ul.Lavoslava Ružičke) je dvosmjerna staza, bic.prijelaz preko ceste uz zebru je isto dvosmjeran a dalje nema ucrtane trake na nogostupu (t.j. ispred nebodera) niti znaka s ove strane a s druge strane (t.j. kad ides od Vukovarske) ima plavog znaka za pjesacku + biciklisticku stazu (bicikl+pjesak u plavom krugu) stavio sam sliku na openstreetview samo da ce to potrajati dok prođe proceduru.. Ja bih to ucrtao kao * Jednosmjerna biciklistička staza bez trake** **(puna žuta linija sa strelicama)* - highway=pedestrian + bicycle=designated + segregated=no + oneway=yes iz uputa za biciklisticku kartu Zagreba.. Pozdrav Hynek On 25.4.2012 16:51, Janko Mihelić wrote: 2012/4/25 Hynek Suchy suc...@gmail.com Bok! Također sam htio pitati za označavanje staza - što bi točno značilo jednosmjerna biciklistička staza bez trake (puna žuta linija sa strelicama) iz uputa za označavanje je li je to staza koja je označena samo prometnim znakom a ne trakom na nogostupu? Jer takvih ima nekoliko...napr od križanja Vukovarske i Lučićeve u Lučićevoj ulici uz Mamićev neboder nema ucrtane trake ali postoji znak.. Možda ste već vodili diskusiju o tome a ja nisam to pročitao.. Hvala na odgovoru! Hynek (suchyh) To bi bila staza gdje nema trake na pločniku, ima znaka, ali samo sa jedne strane. Mislim da je trenutno tako izmapirana samo jedna staza, traka južno od Avenue Malla. Postoji znak na sjeveru tog pločnika, okrenut prema sjeveru, ali nema na jugu. Pretpostavljam da je to jednosmjerna staza bez trake. Nisam znao da ima kod Mamićevog tornja. Ima li znakova sa obje strane? Janko ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk] Bing coverage relations, in particular 1298962
Am 27.04.2012 03:28, SomeoneElse: I noticed this while looking at the map here: http://www.openstreetmap.org/?lat=32.001059lon=34.825519zoom=18layers=M The Hires coverage of Bing imagery in the Near East label is from the name on this relation: http://www.openstreetmap.org/browse/relation/1298962 Regardless of the perhaps the map shouldn't render unknown things just because of name=blah issue, I'd argue that metadata such as this really doesn't belong in OSM. I've messaged the three previous editors of this relation and two haven't objected to it's removal (the other one hasn't replied). Can anyone put forward a good reason why it should be kept? I can't see a good reason given there is a website such as http://ant.dev.openstreetmap.org/bingimageanalyzer/ that shows you Bing worldwide highres coverage. Claudius ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Help! Widescale mass problems introduced by user exMajor
User exMajor (http://www.openstreetmap.org/user/eXmajor) has been causing a lot of trouble in the UAE. For months (s)he has been blindly mapping using Bing, not account for offsets, drawing buildings around stationary airplanes [1], mapping tracks as highway=construction[2], mapping mangroves as scrub [3] and so on. I've repeatedly asked him/her to stop but to no avail. If I revert the edits he just reverts them back. Now in a series of changesets starting roughly around the 14th April this same user has caused wholesale vandalism in Abu Dhabi city, deleting roads, adding hundreds of parking nodes [4], deleting entire districts, changing minor roads to tertiary etc. Here (http://www.openstreetmap.org/?lat=24.43726lon=54.41217zoom=17layers=M) is a typical example, with a block's worth of roads removed, leaving three orphan segments. Just pan around and see the mess. It appears that I can not stop this user, so I'm appealing to the community to help stop this before he screws up the entire UAE. [1] http://www.openstreetmap.org/?lat=25.580147lon=55.653601zoom=18layers=M [2] http://www.openstreetmap.org/?lat=25.580147lon=55.653601zoom=18layers=M [3] http://www.openstreetmap.org/?lat=25.77614lon=55.95995zoom=15layers=M [4] http://www.openstreetmap.org/?lat=24.43389lon=54.4482zoom=16layers=M -- Charlie ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] near by
On Fri, Apr 27, 2012 at 5:02 PM, Ramiro Cosentino ramaug...@gmail.com wrote: Yes, sure. What I mean is I have different pre-loaded locations (restaurants, hotels, etc. ) already stored with their lon/lat on the phone's database, and I'd like to show all of them which are in the range of, let's say, 20 blocks near the user's current location. As Richard points out, the easiest thing for you to do is decide what a block is in some measurement system (ala meters). From there you can determine the radius you'll need to work out. You shouldn't use the OSM servers directly from your phone's app, but you may be able to get permission from, say the MapQuest one (I can't speak for them, but they have fairly generous terms). Now, an XAPI call requires a bounding box, so you'll need to calculate your radius to a degrees, and your circle to a square. Once you do that, you're ready to make your XAPI call. http://open.mapquestapi.com/xapi/ That page uses an improved version of a little cutsey frontend I wrote a long time ago (theirs is nicer!). if you're unfamiliar with OSM's tagging system, you should spend some time on the wiki, or watch the videos I put out about a year ago that cover OSM basics: http://www.youtube.com/playlist?list=PLCE6296A33CF47955feature=mh_lolz - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help! Widescale mass problems introduced by user exMajor
On 28.04.2012 14:00, Charlie Ferrero wrote: User exMajor (http://www.openstreetmap.org/user/eXmajor) has been causing a lot of trouble in the UAE. [...] if necessary please contact the Data Working Group ( http://wiki.openstreetmap.org/wiki/Data_working_group ) via d...@osmfoundation.org. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
* Frederik Ramm (frede...@remote.org) wrote: There's nothing keeping one from applying the Tiles@Home lowzoom process to a slight variation of our standard Mapnik style however, and out comes this (for zoom levels 0-8; from z9 on, the standard Mapnik style looks fine): http://fred.dev.openstreetmap.org/lowzoom/ It so happened that I was experimenting with the same thing in Feb, and this week I've finished the utility which can combine highzoom tiles into lowzoom ones and apply overlays in a fast and easy way, and I though you (and others) may be interested in it. Wiki: http://wiki.openstreetmap.org/wiki/Tiletool Source docs: https://github.com/AMDmi3/tiletool Example rendering from z9 mapnik tiles (plain, no captionless tiles and overlays): http://lowzoom.osm.rambler.ru/ -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] kein Tracks hochladen
Am 28.04.2012 07:01, schrieb Bernd Wurst: Man muss weder an unüblicher Stelle noch zu schnell unterwegs gewesen sein. Und dennoch kann man frei entscheiden seinen Track nicht zu veröffentlichen. Das ist einer der wichtigsten Grundsätze beim Datenschutz. Auch unverfängliche Daten dürfen und sollen geschützt werden. Das ist völlig in Ordnung. Allerdings mapt man ja nicht nur Wegeverläufe, sondern auch restrictions, Abbiegeverbote, Straßenzustand pipapo. Ein GPS-Track zeigt auch: ich war da und erhöht ein wenig die Glaubwürdigkeit. Ok, seit brauchbare Luftbilder zur Verfügung stehen, ist die Bedeutung zurückgegangen. Aber die zeigen auch nicht alles, manches, was bei Bing wie ein Weg aussieht, ist keineswegs befahrbar. Achja, restrictions. Was tut man damit: http://wiki.openstreetmap.org/wiki/File:Restrictions_marsbruchplatz_aplerbeck_IMGP5729.jpg (short: http://preview.tinyurl.com/cxqzz7l ) betreffend http://www.openstreetmap.org/browse/way/30504716 -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28. April 2012 11:22 schrieb Rainer Knaepper sm...@gmx.de: Was tut man damit: http://wiki.openstreetmap.org/wiki/File:Restrictions_marsbruchplatz_aplerbeck_IMGP5729.jpg (short: http://preview.tinyurl.com/cxqzz7l ) betreffend http://www.openstreetmap.org/browse/way/30504716 highway=residential oneway=yes oneway:bicycle=no und/oder cycleway=opposite access=destination bicycle=yes taxi=yes noexit=yes maxspeed=20 Habe ich etwas übersehen? Parkverbotszone fällt mir gerade nicht ein. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28. April 2012 11:46 schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 28. April 2012 11:22 schrieb Rainer Knaepper sm...@gmx.de: Was tut man damit: http://wiki.openstreetmap.org/wiki/File:Restrictions_marsbruchplatz_aplerbeck_IMGP5729.jpg (short: http://preview.tinyurl.com/cxqzz7l ) betreffend http://www.openstreetmap.org/browse/way/30504716 highway=residential oneway=yes oneway:bicycle=no und/oder cycleway=opposite access=destination bicycle=yes taxi=yes noexit=yes maxspeed=20 Habe ich etwas übersehen? Parkverbotszone fällt mir gerade nicht ein. Fußgänger vergessen. Ich würde motor_vehicle=destination taggen, anstatt access=destination, dann kannst Du Dir das bicycle=yes sparen (und ggf. auch taxi=yes, aber wenn es schon explizit dransteht, schadet es wohl auch nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28.04.2012 12:04, schrieb Martin Koppenhoefer: Am 28. April 2012 11:46 schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 28. April 2012 11:22 schrieb Rainer Knaepper sm...@gmx.de: Was tut man damit: http://wiki.openstreetmap.org/wiki/File:Restrictions_marsbruchplatz_aplerbeck_IMGP5729.jpg (short: http://preview.tinyurl.com/cxqzz7l ) betreffend http://www.openstreetmap.org/browse/way/30504716 highway=residential oneway=yes oneway:bicycle=no und/oder cycleway=opposite access=destination bicycle=yes taxi=yes noexit=yes maxspeed=20 Habe ich etwas übersehen? Parkverbotszone fällt mir gerade nicht ein. Fußgänger vergessen. Ich würde motor_vehicle=destination taggen, anstatt access=destination, dann kannst Du Dir das bicycle=yes sparen (und ggf. auch taxi=yes, aber wenn es schon explizit dransteht, schadet es wohl auch nicht). Gruß Martin Ich würde das bicycle=yes so lassen und vehicle=destination statt access=destination notieren. Und ferner würde ich noch *source:maxspeed*=DE:zone20 hinzufügen. Gruß Andre ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
2012/4/28 Martin Koppenhoefer dieterdre...@gmail.com: Am 28. April 2012 11:46 schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 28. April 2012 11:22 schrieb Rainer Knaepper sm...@gmx.de: Was tut man damit: http://wiki.openstreetmap.org/wiki/File:Restrictions_marsbruchplatz_aplerbeck_IMGP5729.jpg (short: http://preview.tinyurl.com/cxqzz7l ) betreffend http://www.openstreetmap.org/browse/way/30504716 highway=residential oneway=yes oneway:bicycle=no und/oder cycleway=opposite access=destination bicycle=yes taxi=yes noexit=yes maxspeed=20 Habe ich etwas übersehen? Parkverbotszone fällt mir gerade nicht ein. Fußgänger vergessen. Ich würde motor_vehicle=destination taggen, anstatt access=destination, dann kannst Du Dir das bicycle=yes sparen (und ggf. auch taxi=yes, aber wenn es schon explizit dransteht, schadet es wohl auch nicht). Aber Zeichen 250 spricht doch nur ein Verbot für Fahrzeuge aller Art aus.[1] Fußgänger sind doch keine Fahrzeuge, dürfen also immer passieren. [1] http://www.gesetze-im-internet.de/stvo/anlage_2_64.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Michael Kugelmann schrieb: Am 27.04.2012 11:54, schrieb Jimmy_K: Viele mapper laden nicht alle ihre Tracks hoch, ist bei mir genauso. Mache ich auch nicht. Ersten erfordert es Arbeit sie auszumisten [...] sondern als Straßenverlauf interpretiert wird. Ich gibt mehrere Gründe warum es viele Personen nicht machen: * das Aussortieren von schlechtem Empfang ist schlichtweg Aufwand der zum Nutzen nicht gerechtfertigt ist Machen meinem Eindruck nach Wenige. Sobald man etwas längere Logs hat, skaliert das eh nicht mehr. Funktionierende Batchverarbeitung zum Säubern von Logs gibt es nicht. * Aufwand für das Hochladen (langsam und dazu ein umständliches Userinterface: Track für Track einzeln) * Es gibt auch kein Offline-Programm um viele Tracks in bequemer Weise hochzuladen (in eine Liste und das Programm macht den Rest dann automatisch z.B. über Nacht) Alle Logs in eine Zip-Datei packen, hochladen, fertig. * in der Vergangeheit gab es schon Probeme, dass die Tracks vom Server nicht akzeptiert wurden Ist mir (iirc) nie passiert) * Datenschutz: es geht nicht jeden an [...] man kann die Logs als Sammlung anonymer Punkte veröffentlichen * weiß nur der Mapper wo er langefahren ist (Beispiele) Wenn ich irgendwo mit zwei Loggern im Wald unterwegs war und die Qualität der Logs entsprechend schlecht ist freue ich mich, wenn die miese Qualität durch die Vermittelung mit den hochgeladenen Logs Anderer verbessert werden kann. Am Anfang des Projekts musste sich OSM rechtfertigen wo die Daten herkommen = die Tracks waren ein Beweis, dass die Leute wirklich da waren und die Daten nicht kopiert wurden. Zwischenzeitlich hat das Projekt aber ein gewisses Ansehen weil wir uns konsequent für die Sauberkeit der Daten einsetzen. Dass wir uns dafür einsetzen heißt nicht zwangsläufig, dass die Daten auch sauber /sind/. Siehe z.B. http://wiki.openstreetmap.org/wiki/Import/Catalogue#Imports_slated_for_deletion Und es stehen zwischenzeitlich Quellen (z.B. gute Luftbilder) zur Verfügung um Daten auch ohne Besuch vor Ort zu erfassen = die Tracks sind m.E. nicht mehr zwingend nötig. Wie kann wohl der Mapper daheim am Rechner überprüfen, ob die Luftbilder korrekt sitzen beziehungsweise deren Lage korrigieren..? Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Hallo. Am 28.04.2012 11:22, schrieb Rainer Knaepper: Ein GPS-Track zeigt auch: ich war da und erhöht ein wenig die Glaubwürdigkeit. Das ist richtig und auch okay. Zumindest so lange man aus anderem Anlass Grund zum Zweifel hat. Aber man darf nicht dem (naheliegenden) Fehlschluss ziehen, dass Mapper ohne Track entsprechend grundsätzlich unglaubwürdiger wären. Gruß, Bernd -- Kann man in geschmolzenem Trockeneis schwimmen, ohne naß zu werden? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Bernd Wurst wrote Nicht jeder der personenbezogene Daten nicht veröffentlichen möchte hat etwas verbotenes getan. Man muss weder an unüblicher Stelle noch zu schnell unterwegs gewesen sein. Und dennoch kann man frei entscheiden seinen Track nicht zu veröffentlichen. Moin Wenn ich mit Gps-Tracks arbeite, benutze ich die lokal mit Josm auf meinem Rechner (Datei Laden, ...). Und wenn ich dann -endlich- fertig damit bin, vergesse ich fast immer, dass ich den Track auch noch hochladen sollte. Nun ist mir meine Platte abgeraucht und ich überdenke mal meine Arbeitsweise :( Aber böse Absicht oder Datenschutz steckt zumindest bei mir nicht dahinter. Gruss Walter -- View this message in context: http://gis.19327.n5.nabble.com/Copy-Paste-remaper-tp5668826p5672445.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Walter Nordmann schrieb: Nun ist mir meine Platte abgeraucht und ich überdenke mal meine Arbeitsweise :( Auch hinsichtlich Backups? *scnr* malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geografische Regionen innerhalb der Datenbank?
Moin zusammen! Für ein Studienprojekt benötige ich aktuell geografische Regionen der Erde in verschiedenen Abstufungen. Also sowas wie Europa und darin Nordeuropa, Westeuropa und so weiter (idealerweise bis auf Stadtebene, aber das ist nicht so wichtig, ich nehme was ich kriegen kann). Existieren diese Daten irgendwo innerhalb der OSM-Datenbank, so dass ich mir die daher extrahieren könnte? Falls nein, weiß jemand um eine andere Datenquelle wo ich sowas herbekomme? Wichtig ist mir eigentlich nur, dass ich die Bezüge der Regionen aus den Daten ableiten kann (also Anfragen gestalten kann wie Welche Subregionen liegen in Nordeuropa oder in welche Subsubregion liegt München). Da das Projekt, in dem das verwendet werden soll, ggf. auch direkt mit OSM-Daten arbeiten wird, wäre es halt schön, wenn ich die Daten direkt aus OSM hätte, dann fällt das verknüpfen später leichter. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28 Apr 2012 um 12:26 schrieb Falk Zscheile falk.zsche...@googlemail.com: Aber Zeichen 250 spricht doch nur ein Verbot für Fahrzeuge aller Art aus.[1] Fußgänger sind doch keine Fahrzeuge, dürfen also immer passieren. Das stimmt schon, deshalb passt ja auch Access nicht. Access gilt für alle, wenn nur Fahrzeuge ausgeschlossen werden sollen, ist ein anderes tag angebracht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Sieh dir mal Natural Earth an, da gibt's sowas. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Hallo Martin. Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem blöden Problem: Geographische Regionen haben oft nicht fest definierte Grenzen. Wo hören die Alpen auf? Wo die norddeutsche Tiefebene? Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn überhaupt) abbilden. Wenn Du da allerdings 'ne gute Idee haben solltest... interessieren würde mich das Thema durchaus. Gruß Peter Am 28.04.2012 13:24, schrieb Martin Thurau: Moin zusammen! Für ein Studienprojekt benötige ich aktuell geografische Regionen der Erde in verschiedenen Abstufungen. Also sowas wie Europa und darin Nordeuropa, Westeuropa und so weiter (idealerweise bis auf Stadtebene, aber das ist nicht so wichtig, ich nehme was ich kriegen kann). Existieren diese Daten irgendwo innerhalb der OSM-Datenbank, so dass ich mir die daher extrahieren könnte? Falls nein, weiß jemand um eine andere Datenquelle wo ich sowas herbekomme? Wichtig ist mir eigentlich nur, dass ich die Bezüge der Regionen aus den Daten ableiten kann (also Anfragen gestalten kann wie Welche Subregionen liegen in Nordeuropa oder in welche Subsubregion liegt München). Da das Projekt, in dem das verwendet werden soll, ggf. auch direkt mit OSM-Daten arbeiten wird, wäre es halt schön, wenn ich die Daten direkt aus OSM hätte, dann fällt das verknüpfen später leichter. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefgragen
Hi alle und Falk, Am 14.04.2012 11:50, schrieb Falk Zscheile: So, ich habe meine Lösung hier: http://wiki.openstreetmap.org/wiki/DE_talk:Tag:amenity%3Dparking dokumentiert und freue mich über Kommentare. Ich hätte gerne ein paar Beispiele (OSM-IDs oder Links auf die Karte), bitte hier auf die Liste (und am Besten auch gleich in's Wiki). Hintergrund: ich würde das gerne auf der Parkkarte korrekt darstellen. Danke, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Unter Denkmalschutz stehen de Gebäude
Jeder Ort hat ja dutzende / Hunderte von unter Schutz stehenden Gebäuden usw. sollen die, können die vermerkt werden? Beispiel: http://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Simmerath macht das überhaupt Sinn? Grüße aus der Eifel Steffen -- Ich verwende die kostenlose Version von SPAMfighter für private Anwender, die bei mir bis jetzt 8890 Spammails entfernt hat. Rund 7 Millionen Leute nutzen SPAMfighter schon. Laden Sie SPAMfighter kostenlos herunter: http://www.spamfighter.com/lde ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefgragen
Am 28. April 2012 17:15 schrieb Kay Drangmeister k...@drangmeister.net: Am 14.04.2012 11:50, schrieb Falk Zscheile: So, ich habe meine Lösung hier: http://wiki.openstreetmap.org/wiki/DE_talk:Tag:amenity%3Dparking dokumentiert und freue mich über Kommentare. Ich hätte gerne ein paar Beispiele (OSM-IDs oder Links auf die Karte), bitte hier auf die Liste (und am Besten auch gleich in's Wiki). Hintergrund: ich würde das gerne auf der Parkkarte korrekt darstellen. Aber gern doch. Mehr als zwei Beispiele habe ich leider nicht. 1. Beispiel: http://www.openstreetmap.org/browse/relation/2135015 Wobei es noch nicht ganz dem Vorschlag des Proposels entspricht. Ich habe die Node mit der Tiefgarage belassen, damit man sie in der Mapnikkarte noch sieht: http://www.openstreetmap.org/browse/node/864659895 2. Beispiel: http://www.openstreetmap.org/browse/relation/2135012 Bei diesem Beispiel ist das Tiefgaragentag ausschließlich in der Relation zu finden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28. April 2012 15:11 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 28 Apr 2012 um 12:26 schrieb Falk Zscheile falk.zsche...@googlemail.com: Aber Zeichen 250 spricht doch nur ein Verbot für Fahrzeuge aller Art aus.[1] Fußgänger sind doch keine Fahrzeuge, dürfen also immer passieren. Das stimmt schon, deshalb passt ja auch Access nicht. Access gilt für alle, wenn nur Fahrzeuge ausgeschlossen werden sollen, ist ein anderes tag angebracht. Ok, also so, wie es Andre vorgeschlagen hat: Anstatt access=destination besser motor_vehicle=destination? Wobei Zeichen 250 ja eigentlich vehicle=destination wäre. motor_vehicle wäre ja eigentlich Zeichen 251. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Am 28. April 2012 15:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem blöden Problem: Geographische Regionen haben oft nicht fest definierte Grenzen. Wo hören die Alpen auf? Wo die norddeutsche Tiefebene? Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn überhaupt) abbilden. Wenn Du da allerdings 'ne gute Idee haben solltest... interessieren würde mich das Thema durchaus. Da wurde etwas für API 0.7 zu Diskussion gestellt, aber nicht weiter erläutert und für mich bisher auch nicht überzeugend: http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude
Am Samstag, 28. April 2012, 18:03:38 schrieb Steffen Heinz: Jeder Ort hat ja dutzende / Hunderte von unter Schutz stehenden Gebäuden usw. sollen die, können die vermerkt werden? Beispiel: http://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Simmerath macht das überhaupt Sinn? Ich habe vereinzelt schon Gebäude mit dem NRW-Wappen und Denkmal oder der blau-weißen Raute ganz pragmatisch mit heritage=yes getaggt. Muss nicht korrekt sein, aber man kann es später immer noch ändern. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Am Samstag, 28. April 2012, 18:58:09 schrieb Falk Zscheile: Am 28. April 2012 15:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem blöden Problem: Geographische Regionen haben oft nicht fest definierte Grenzen. Wo hören die Alpen auf? Wo die norddeutsche Tiefebene? Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn überhaupt) abbilden. Wenn Du da allerdings 'ne gute Idee haben solltest... interessieren würde mich das Thema durchaus. Da wurde etwas für API 0.7 zu Diskussion gestellt, aber nicht weiter erläutert und für mich bisher auch nicht überzeugend: http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions Wozu braucht man dafür eine neue API-Version? Ließe sich doch auch mit der bisherigen Software eintragen. Vielleuicht mit Relationen, die die Hierarchien nachbilden und Mulipolygonen oder Wegen, die die Bereiche grob markieren. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Am 28.04.2012 12:32, schrieb malenki: Alle Logs in eine Zip-Datei packen, hochladen, fertig. Und alle mit selber Beschreibung? Macht für mich keinen Sinn. Wie kann wohl der Mapper daheim am Rechner überprüfen, ob die Luftbilder korrekt sitzen beziehungsweise deren Lage korrigieren..? Nur als Anmerkung: ein GPS kann von der Genauigkeit auch nicht unwesentlich streuen... Und: ich vertraue nur meinen eigenen Tracks. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Am 28. April 2012 19:18 schrieb Alexander Matheisen alexandermathei...@ish.de: Am Samstag, 28. April 2012, 18:58:09 schrieb Falk Zscheile: Am 28. April 2012 15:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem blöden Problem: Geographische Regionen haben oft nicht fest definierte Grenzen. Wo hören die Alpen auf? Wo die norddeutsche Tiefebene? Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn überhaupt) abbilden. Wenn Du da allerdings 'ne gute Idee haben solltest... interessieren würde mich das Thema durchaus. Da wurde etwas für API 0.7 zu Diskussion gestellt, aber nicht weiter erläutert und für mich bisher auch nicht überzeugend: http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions Wozu braucht man dafür eine neue API-Version? Ließe sich doch auch mit der bisherigen Software eintragen. Vielleuicht mit Relationen, die die Hierarchien nachbilden und Mulipolygonen oder Wegen, die die Bereiche grob markieren. Keine Ahnung, dass musst du den Fragen, der sich das ausgedacht hat. ICh wollte nur darauf hinweisen, das dort so etwas steht. Vielleicht wäre es sinnvoller eine zweiten layer einzuführen, in dem wir alle virtuellen Elemente packen. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Am 28.04.2012 19:18, schrieb Alexander Matheisen: Am Samstag, 28. April 2012, 18:58:09 schrieb Falk Zscheile: Da wurde etwas für API 0.7 zu Diskussion gestellt, aber nicht weiter erläutert und für mich bisher auch nicht überzeugend: http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions Wozu braucht man dafür eine neue API-Version? Ließe sich doch auch mit der bisherigen Software eintragen. Vielleuicht mit Relationen, die die Hierarchien nachbilden und Mulipolygonen oder Wegen, die die Bereiche grob markieren. So, wie es da vorgeschlagen ist, braucht man sicher keine neue API-Version, um das einzuführen. Die Frage, die auf mindestens einer Mailingliste schonmal diskutiert wurde, war jedoch, ob das reicht. Geographische Regionen haben keine scharfen Ränder, sondern ziemlich schwammige Grenzen, und so etwas lässt sich momentan tatsächlich nicht abbilden. Die Formulierung im Wiki beim Vorschlag für 0.7 geht jedoch darauf überhaupt nicht ein. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude
Hallo, am 28.04.2012 18:03 schrieb Steffen Heinz: Jeder Ort hat ja dutzende / Hunderte von unter Schutz stehenden Gebäuden usw. sollen die, können die vermerkt werden? Beispiel: http://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Simmerath macht das überhaupt Sinn? Ja, das ist sinnvoll. Es ist m.E. wichtiger, die geschützten Kulturdenkmäler zu dokumentieren, als Drogeriemarktkettenfilialen. Nur wie? Es gibt keinen allgemein akzeptierten Tag dafür. JOSM bietet Vorlage Baudenkmal an, die den Tag historic=monument nutzt. Das ist nicht überein mit dem Wiki. Weil ich so gekennzeichnet hatte, gab es dazu schon heftige Diskussionen und manche Kennzeichnung ist wieder weg. Meine Lösung bis zu einem speziellen Tag: Jedes Baudenkmal bekommt folgende zusätzliche Ausstattung: description=Baudenkmal LFD OBJ-Dok-Nr. website=Link auf die Ergebnisseite zu dem Objekt in der LfD-Datenbank wikipedia=de:Denkmalliste#Anker Website geht nur, wenn nicht anderweitig benötigt (sonst Ergänzung in description möglich. wikipedia zeigt nicht auf die Denkmalliste, wenn es zu dem Objekt einen Artikel gibt. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Geographische Regionen haben keine scharfen Ränder, sondern ziemlich schwammige Grenzen, und so etwas lässt sich momentan tatsächlich nicht abbilden. Das kann man ja beim Auswerten berücksichtigen. Etwa eine Ungenauigkeit von +/- 20km bei Mittelgebirgen vielleicht... Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Luftbilder (Aerowest) für Schwetzingen und Umgebung via TMS verfügbar
Hallo @talk-de,
nachdem Stephan schon vor einigen Tagen die Verfügbarkeit von
Aerowest-Bildern für Bonn und Umgebung via TMS ankündigen und weitere
Bilder versprechen durfte [1], erfülle ich mit großer Freude einen Teil
seines Verprechens und ziehe mit weiteren Aerowest-Luftbildern nach :)
Die Bilder sind:
* Schwetzingen
* Plankstadt
* Brühl (Baden)
* Ketsch (Rhein)
Alle Bilder haben eine ursprüngliche Bodenauflösung von 7 cm/px.
Dementsprechend liefert der TMS-Server Tiles auf Zoomlevels von 12 bis
21 aus. Anders als in Bonn, wo die einzelnen Aerowest-Datensätze auch
einzeln in Editoren einzubinden sind, sind hier die vier Datensätze zu
einem TMS-Layer vereinigt, da sie ohnehin ein zusammenhängendes Gebiet
darstellen.
Der Layer wird in nächster Zeit um Luftbilder von Mannheim, Ludwigshafen
und Oftersheim erweitert, nachdem die Verarbeitung beendet ist.
Die Bilder stehen in dieser Form voraussichtlich bis zum 15.07.2012 zur
Verfügung.
Einbindung in JOSM:
tms:http://vwi-stuttgart.de:8080/aerowest-baden/{zoom}/{x}/{y}.jpg
Einbindung in Potlatch:
http://vwi-stuttgart.de:8080/aerowest-baden/$z/$x/$y.jpg
Viel Spaß und Erfolg beim Verbessern von OpenStreetMap - mögen die
Luftbilder euch dabei helfen :) Lob, Kritik, Anregungen und Wünsche sind
natürlich immer willkommen :)
Weitere Informationen zum Projekt:
http://wiki.openstreetmap.org/wiki/DE:WissensWert/Luftbilder
Mein Dank geht an alle, die dies möglich gemacht haben:
* an Marc Gehling und Olaf Kotzte für die Vermittlung zu Aerowest
* an meinen Arbeitgeber VWI Stuttgart GmbH für die Bereitstellung des
Servers und diverser Ressourcen zur Verarbeitung der Bilder
* an Paul Hartmann, Edbert van Eimeeren, Stephan SB79 B., Paul
Hartmann und Michael Schulze für die Unterstützung in der Projektgruppe
* an die Entwickler von GDAL, PROJ.4, Rasterlite, PIL, Python und rsync
für ihre großartige (wenn gelegentlich auch etwas eigenwillige ;)) Software
Viele Grüße aus Stuttgart
Igor
[1] http://lists.openstreetmap.org/pipermail/talk-de/2012-April/095055.html
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude
Am 28.04.2012 21:17, schrieb Norbert Kück: website=Link auf die Ergebnisseite zu dem Objekt in der LfD-Datenbank Das wird zwar fast schon off-topic, aber website ist für Links auf die offizielle Webseite eines Objekts (also z.B. die vom Inhaber betriebene Seite über ein Geschäft, oder den Internetauftritt einer Schule etc.), nicht für irgendeine URL, wo etwas über das Objekt steht. Dein Beisiel ist also eine falsche Verwendung dieses Schlüssels. Website geht nur, wenn nicht anderweitig benötigt Genau sowas wird bei korrekter Verwendung von website nie vorkommen, da es zwar viele Seiten geben mag, auf denen etwas über das Objekt steht, aber _die_ Webseite des Objekts normalerweise eindeutig ist. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude
Norbert Kück wrote description=Baudenkmal LFD OBJ-Dok-Nr. website=Link auf die Ergebnisseite zu dem Objekt in der LfD-Datenbank wikipedia=de:lt;Denkmalliste#Ankergt; Hi Norbert - Die Lfn könnte/sollte man in ref=* packen. - einen Link zu einer Webseite braucht man nicht, da der für alle Baudenkmäler identisch sein kann. - der wikipedia-link halt nach Bedarf so wie bei allen anderen WP-Links - plus heritage=yes oder was auch immer. Auswertung/Anwendung: wenn heritage=yes - externe daten stehen auf xxx.yyy.zz/data/ref Knackpunkt: Server-Url steht nicht in den OSM-Daten sondern in der externen Projektbeschreibung. Gruss Walter -- View this message in context: http://gis.19327.n5.nabble.com/Unter-Denkmalschutz-stehen-de-Gebaude-tp5672807p5673519.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] R: Strade di campagna
On 04/27/2012 09:44 AM, sabas88 wrote: Allora mi chiedo : il tag tracktype non sarebbe utile anche per le strade ? Non basterebbe surface? mentre c'è una differenza tra grade1 a grade2 (~ surface=asphalt/paved, surface=gravel), per la altre tracktype non è così semplice da descrivere soltanto con surface. -- Cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Strade di campagna
2012/4/28 Alexander Roalter alexan...@roalter.it mentre c'è una differenza tra grade1 a grade2 (~ surface=asphalt/paved, surface=gravel), per la altre tracktype non è così semplice da descrivere soltanto con surface. Secondo me non è così semplice come dici neanche tra grade1 e grade2. Per me una strada in macadam è grade1 anche se ha la superficie in ghiaia. Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] app per htc flyer
-Original Message- From: Luca Delucchi [mailto:lucadel...@gmail.com] Sent: giovedì 26 aprile 2012 14:26 To: davide.bagn...@libero.it; openstreetmap list - italiano Subject: Re: [Talk-it] app per htc flyer per mappare direttamente esiste vespucci. poi sia geopaparazzi che osmand permettono di inserire elementi puntuali sul database di osm Per integrare/rivedere zone già mappate può essere utile anche OSMapTuner (non permette l'inserimento di nuovi oggetti, ma solo di editare i tag di quelli esistenti) Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] OpenLayers + OSM + Catastro
Si no me equivoco OpenLayers no reproyecta imágenes, solo coordenadas. Por ejemplo, si tienes por ahí una serie de puntos de interés (hospitales, gasolineras, etc) que quieres dibujar con OpenLayers, se pueden reproyectar a lo que tú quieras, porque es aplicar una fórmula a unos pocos puntos. Pero si tienes una serie de imágenes (teselas) que necesitan ser deformadas entonces creo que no puede hacerlo (creo que la razón era porque sería muy lento con javascript). Eso tiene que venir ya con la proyección correcta desde el servidor. A veces puedes solicitar una proyección diferente al servidor cambiando algún parámetro. También puedes montarte un servidor de OSM con la proyección adecuada. Por lo menos así lo entendí yo una vez que hice cuatro cosas con OpenLayers (corregidme si me equivoco). Respecto a la segunda pregunta, no sé si es posible preguntar a OSM por elementos de cierto tipo dentro de unas coordenadas (no tengo experiencia con la API de OSM). Apostaría a que sí se puede. Una vez recuperados los elementos en OpenLayers puedes renderizarlos como quieras. Hay varios ejemplos en la web de OpenLayers. El 27 de abril de 2012 20:17, Mauro mauro@silenci.net escribió: Hola a todos. Llevo bastante tiempo peleándome con el siguiente problema. Con OpenLayers puedo cargar una capa de OSM y otra del Catastro pero no soy capaz de superponerlas. Además cuando cambio de una capa a otra la imagen del mapa cambia de zoom y cambia de posición. Lo mismo me ocurre con las capas IGN topo [1]. Se que es un problema de la proyección que utiliza OSM EPSG:900913 y la del catastro o el IGN EPSG:4326 pero ha sido imposible encontrar la solución. ¿Alguien tiene un trozo de código que permita superponer la capa del catastro sobre la de OSM? Aprovecho y os pregunto otra duda. He mirado la API del OpenLayers y creo que no se puede hacer lo siguiente. Me gustaría poder realizar consultar a OSM del tipo dame todas las fuentes que se encuentran en esta zona y pintarlos con un icono personalizado en el mapa. ¿Hay algún framework en javascript que lo haga? De no ser así ¿algun servicio que pueda atacar para obtener esa información? Algo parecido a Nominatim pero con atributos. Gracias. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [cat2osm] error al crear el archivo config
También podéis usar alguno de los scripts que vienen en la carpeta scripts (solo en Linux). Generan los archivos config automáticamente, varios a la vez. Al mío le añadí una opción para generar también un config urbano y un config rústico por cada pueblo (además del config estándar). Más fácil y rápido imposible. El 27 de abril de 2012 20:49, Rafael Avila Coya ravilac...@gmail.comescribió: Sí. A mi también me pasa. Cambio a mano el config al final, y ya está. Rafael Ávila. En 27/04/12 14:36, Aitor Freire Astray escribiu: Yo también lo estaba metiendo a mano, pero no sabía si era cosa mía. Gracias. Saludos, El 27 de abril de 2012 14:31, Matías Taborda Barroso taborda.barr...@gmail.com mailto:taborda.barr...@gmail.com escribió: Hola. Si es verdad que pasa eso; yo lo que hago es añadir manualmente PrintShapeIds=0, pero creo que efectivamente el archivo obtenido es el mismo. Saludos. El 27 de abril de 2012 14:26, Aitor Freire Astray aitor.fre...@gmail.com mailto:aitor.fre...@gmail.com escribió: Hola, Al ejecutar -ui con la última versión (2012--04-20) el archivo config que genera no incluye la línea 'PrintShapeIds' y al ejecutar el cat2osm no la encuentra y da error, pero acaba el proceso y el archivo generado parece igual que el obtenido incluyendo la línea en el config. ¿A alguien más le ha pasado? ¿estoy haciendo algo mal o es problema de la versión? Saludos, -- Aitor Freire Astray ___ Talk-es mailing list Talk-es@openstreetmap.org mailto:Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org mailto:Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Aitor Freire Astray ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Dudas sobre mi proyecto
Como en correos anteriores, os comentaba que quiero hacer una mapa de disponibilidad de servicios de mi empresa ( ISP mediante tecnología HFC) y me gustaría montar un server de osm y montarle la capa de catastro (ya que necesito ubicación exacta para los elementos ) y otra de datos (amplificadores, acometidas,...). Cómo monto un server con los datos de OSM y que le pueda subir las capas de catastro (solo en los pueblos que tenemos servicio)? Os aseguro que me he leído todo lo que encontrado pero no encuentro el camino por donde empezar. Un saludo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Dudas sobre mi proyecto
On Sábado, 28 de abril de 2012 12:55:58 José Manuel Díaz Soriano escribió: Como en correos anteriores, os comentaba que quiero hacer una mapa de disponibilidad de servicios de mi empresa ( ISP mediante tecnología HFC) y me gustaría montar un server de osm y montarle la capa de catastro (ya que necesito ubicación exacta para los elementos ) y otra de datos (amplificadores, acometidas,...). Cómo monto un server con los datos de OSM y que le pueda subir las capas de catastro (solo en los pueblos que tenemos servicio)? Os aseguro que me he leído todo lo que encontrado pero no encuentro el camino por donde empezar. Un saludo Resumiendo mucho: Primero, necesitas montar una base de datos postgres con postgis y añadirle los datos actuales de osm. http://www.hyperionreactor.net/blog/how-build-your-own-osm-server-part-1-postgis-and-mapnik Segundo, te bajas el cat2osm, dependencias y los datos del catastro. Los procesas y arreglas con el JOSM http://wiki.openstreetmap.org/wiki/Cat2Osm http://wiki.openstreetmap.org/wiki/Minitutorial_para_cat2osm_Avila Finalmente subes los datos que te salgan de catastro de la misma forma que subiste los de osm. Mi recomendación es que en vez de subir toda españa (o todo el mundo) solo subas lo que sale de catastro, pero juntando previamente dichos datos con lo que haya en la base de datos. Lleva un rato, pero es factible. Además, si subis el resultado a la páginas de resultados de cat2osm correspondiente es posible que se suba a master y ya no os sea necesario tener un servidor propio. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Dudas sobre mi proyecto
Eso es lo que yo buscaba.:D Puedo descargar solo España o me tengo que descargar todo el mundo, porque 21GB son tela ... El 28 de abril de 2012 13:16, Cruz Enrique Borges cruz.bor...@deusto.esescribió: On Sábado, 28 de abril de 2012 12:55:58 José Manuel Díaz Soriano escribió: Como en correos anteriores, os comentaba que quiero hacer una mapa de disponibilidad de servicios de mi empresa ( ISP mediante tecnología HFC) y me gustaría montar un server de osm y montarle la capa de catastro (ya que necesito ubicación exacta para los elementos ) y otra de datos (amplificadores, acometidas,...). Cómo monto un server con los datos de OSM y que le pueda subir las capas de catastro (solo en los pueblos que tenemos servicio)? Os aseguro que me he leído todo lo que encontrado pero no encuentro el camino por donde empezar. Un saludo Resumiendo mucho: Primero, necesitas montar una base de datos postgres con postgis y añadirle los datos actuales de osm. http://www.hyperionreactor.net/blog/how-build-your-own-osm-server-part-1-postgis-and-mapnik Segundo, te bajas el cat2osm, dependencias y los datos del catastro. Los procesas y arreglas con el JOSM http://wiki.openstreetmap.org/wiki/Cat2Osm http://wiki.openstreetmap.org/wiki/Minitutorial_para_cat2osm_Avila Finalmente subes los datos que te salgan de catastro de la misma forma que subiste los de osm. Mi recomendación es que en vez de subir toda españa (o todo el mundo) solo subas lo que sale de catastro, pero juntando previamente dichos datos con lo que haya en la base de datos. Lleva un rato, pero es factible. Además, si subis el resultado a la páginas de resultados de cat2osm correspondiente es posible que se suba a master y ya no os sea necesario tener un servidor propio. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Dudas sobre mi proyecto
En 28/04/12 13:29, José Manuel Díaz Soriano escribiu: Eso es lo que yo buscaba.:D Puedo descargar solo España o me tengo que descargar todo el mundo, porque 21GB son tela ... Si sigues el tutorial de instalación de servidor OSM, verás que puedes modificar el bounding box al generar generate_image.py, para así generar una imagen de España sólo. Es posible que también sólo una C.A., como dice Cruz Enrique. Saludos. El 28 de abril de 2012 13:16, Cruz Enrique Borges cruz.bor...@deusto.es mailto:cruz.bor...@deusto.es escribió: On Sábado, 28 de abril de 2012 12:55:58 José Manuel Díaz Soriano escribió: Como en correos anteriores, os comentaba que quiero hacer una mapa de disponibilidad de servicios de mi empresa ( ISP mediante tecnología HFC) y me gustaría montar un server de osm y montarle la capa de catastro (ya que necesito ubicación exacta para los elementos ) y otra de datos (amplificadores, acometidas,...). Cómo monto un server con los datos de OSM y que le pueda subir las capas de catastro (solo en los pueblos que tenemos servicio)? Os aseguro que me he leído todo lo que encontrado pero no encuentro el camino por donde empezar. Un saludo Resumiendo mucho: Primero, necesitas montar una base de datos postgres con postgis y añadirle los datos actuales de osm. http://www.hyperionreactor.net/blog/how-build-your-own-osm-server-part-1-postgis-and-mapnik Segundo, te bajas el cat2osm, dependencias y los datos del catastro. Los procesas y arreglas con el JOSM http://wiki.openstreetmap.org/wiki/Cat2Osm http://wiki.openstreetmap.org/wiki/Minitutorial_para_cat2osm_Avila Finalmente subes los datos que te salgan de catastro de la misma forma que subiste los de osm. Mi recomendación es que en vez de subir toda españa (o todo el mundo) solo subas lo que sale de catastro, pero juntando previamente dichos datos con lo que haya en la base de datos. Lleva un rato, pero es factible. Además, si subis el resultado a la páginas de resultados de cat2osm correspondiente es posible que se suba a master y ya no os sea necesario tener un servidor propio. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es mailto:cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 tel:944139000%20ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org mailto:Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-at] Graz: OSM-Westen und Pins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Wir haben ja auf den heutigen Grazer Linuxtagen am OSM-Stand OSM-Warnwesten und Pins verkauft. Wir haben sie auf Kommission von http://shop.kernelconcepts.de/ bekommen. Es sind etliche Westen und Pins übriggeblieben, und bevor wir sie wieder nach Deutschland zurückschicken, wollte ich fragen ob irgendwer aus Graz/U noch etwas davon haben will. Die Westen geben wir um EUR 10,- und die Pins um EUR 2,- her, das ist ca. Selbstkostenpreis, die Versandkosten miteinberechnet. Wir werden sie Mitte der Woche wieder zurückschicken, also bitte schnell reservieren! Danke, lg Michi - -- Michael Maier, Student of Telematics @ Graz University of Technology -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPnGsXAAoJEPDJmZ2oE4mGKNcP/Rrglc9+D2d1YFOhtK8uHkO2 oUE7d1SiI4hT9duboxUNwrtmiE9iIYdLVRKzhXClZ75JuvUG4n1NqhwpkyR4+6DV Ll1FgV514WUbYKVbKdnd2PZ3MBV3HvHlRWePeFPM/gqjhw71xVel224FShNg+Gb5 ycEs+4MmlyMz4Ru+uEM1VlrjKm+vXCZIsEkGfkk1Ff1VKg+tb1RJuUfFnN9GoHqn VuB27TCG/gh3CfOtsPl1Fku7Prdxweay+bMDlDZwq5gL8+aCOouooI24xlQeL9j+ k7B8g/XIVzalCczI/6Izs7Ch6yTcJBeNiyb2zoO6EQzfTY7FiGkC6D2jz5bh6FkT xAoJTgxXSORUu+ky6kLFjHpuZXceINEa+QvrxYyy2xOgEcIPJjtIrhbe6uGBJw5I IFl1T+xRareuQfaA2KjqBtUB6tU0q6ZM6wE6g0QDGBvW+GEpSeWbZC10iKSa7DL/ wJvOuEol5yQ9ZBrNexSlsYQ2YI9mvlxaxpXTiZt8v6k2KF8M9IpLLwBkGIrzvmwX NUPGg2wSzZxjGjFPqXceVdheqMPlfWLtZeGzsQdLJ8mOqJsYgUSLlusY+QSqdbIX b7X5B0sbyFkSZJSxltFIiwRqvUkybXCVsCS+SERNqEpRwdV9YIe7Kw8txZ68H7O4 eE1pTjl3R91QUkFjq5nQ =eUeX -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-lv] Lietotājs UrSuS
Sveiki! Vai kāds zin UrSuS lietotāju? Ir pāris jautājumi par kartēšanas praksi. Pēteris. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Sveiks :)
Sveiki! Es dodu priekšroku relācijam jo man personīgi nepatīk dublēt datus (zīmēt vel vienu līniju caur tiem pašiem nod'iem), ka ari vēlāk tas pašas sienas var izmantot citam micromapping vajadzībām. 2012/4/28 Peteris Krisjanis pec...@gmail.com: Sveiks! Man ir jautājums tīri teorētisks - tu bieži veido māju relācijas no atsevišķām sienām. Man tas šķiet sarežģīti un nepārskatāmi. Ir kāds iemesls kādēļ? Lai sokas ar kartēšanu! :) Pēteris. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Sveiks :)
Ka piemēru gribēju minēt Berga bazaru http://www.openstreetmap.org/?lat=56.950702lon=24.123874zoom=18layers=M un paskatījos ka pēc mani tur iav dažas vietās sazīmēja footway caur peredstrian area, man līkas tie ir lieki dati. 2012/4/28 Marat mar...@gmail.com: Sveiki! Es dodu priekšroku relācijam jo man personīgi nepatīk dublēt datus (zīmēt vel vienu līniju caur tiem pašiem nod'iem), ka ari vēlāk tas pašas sienas var izmantot citam micromapping vajadzībām. 2012/4/28 Peteris Krisjanis pec...@gmail.com: Sveiks! Man ir jautājums tīri teorētisks - tu bieži veido māju relācijas no atsevišķām sienām. Man tas šķiet sarežģīti un nepārskatāmi. Ir kāds iemesls kādēļ? Lai sokas ar kartēšanu! :) Pēteris. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Sveiks :)
Nav gan tie ir must have dati Viesturs On Apr 28, 2012 11:24 AM, Marat mar...@gmail.com wrote: Ka piemēru gribēju minēt Berga bazaru http://www.openstreetmap.org/?lat=56.950702lon=24.123874zoom=18layers=M un paskatījos ka pēc mani tur iav dažas vietās sazīmēja footway caur peredstrian area, man līkas tie ir lieki dati. 2012/4/28 Marat mar...@gmail.com: Sveiki! Es dodu priekšroku relācijam jo man personīgi nepatīk dublēt datus (zīmēt vel vienu līniju caur tiem pašiem nod'iem), ka ari vēlāk tas pašas sienas var izmantot citam micromapping vajadzībām. 2012/4/28 Peteris Krisjanis pec...@gmail.com: Sveiks! Man ir jautājums tīri teorētisks - tu bieži veido māju relācijas no atsevišķām sienām. Man tas šķiet sarežģīti un nepārskatāmi. Ir kāds iemesls kādēļ? Lai sokas ar kartēšanu! :) Pēteris. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Sveiks :)
Principa varetu vinus automatiski uzgeneret prieks routinga, bet neviens to nedara. On Apr 28, 2012 11:56 AM, Viesturs Zarins viest...@gmail.com wrote: Nav gan tie ir must have dati Viesturs On Apr 28, 2012 11:24 AM, Marat mar...@gmail.com wrote: Ka piemēru gribēju minēt Berga bazaru http://www.openstreetmap.org/?lat=56.950702lon=24.123874zoom=18layers=M un paskatījos ka pēc mani tur iav dažas vietās sazīmēja footway caur peredstrian area, man līkas tie ir lieki dati. 2012/4/28 Marat mar...@gmail.com: Sveiki! Es dodu priekšroku relācijam jo man personīgi nepatīk dublēt datus (zīmēt vel vienu līniju caur tiem pašiem nod'iem), ka ari vēlāk tas pašas sienas var izmantot citam micromapping vajadzībām. 2012/4/28 Peteris Krisjanis pec...@gmail.com: Sveiks! Man ir jautājums tīri teorētisks - tu bieži veido māju relācijas no atsevišķām sienām. Man tas šķiet sarežģīti un nepārskatāmi. Ir kāds iemesls kādēļ? Lai sokas ar kartēšanu! :) Pēteris. ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
[Talk-ca] Introduction and questions
Hi I would like to introduce myself to the group. I currently live in Kanata, I've been mapping trails and paths in Kanata while biking, as many other users do as hobby, I thought it would be interesting to add those unmapped trails somewhere and I found OSM project. Basically I'd like to check if I'm doing it all right. Talking about mixed paths where both walking and biking is allowed, I was following the same descriptions of nearby paths, i.e. highway=footpath; bicycle=yes, but I found in the wiki that it is better set them as highway=path, bicycle=yes, foot=yes. That means updating several existing paths. Is that okay? Also we have some recognized mountain bike trails as result of a great work carried by the Ottawa Mountain Bike Association. I'd like to add trail names and other mtb related info. Finally I'm adjusting some natural features like green areas that had been reduced due development, new construction sites and clear cuts. Some areas already have streets and houses mapped, some are recognisable on bing aerial images but some aren't. I'm just concerned about the lack of official source, since in some cases the source is what I see. I appreciate any help or guideline. http://www.openstreetmap.org/user/dfmarx/edits http://www.openstreetmap.org/user/dfmarx/traces Cheers, Daniel Marques ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Introduction and questions
I live on the other side of town, Orleans, cycle paths are a problem area in that the city is adding a fair chunk each year but their licensing is problematic so the best way to capture them is by local knowledge. Local knowledge is also best for the new developments as well. Bing etc can be three years or more out of date. Tags, the more consistency there is the easier it is to render so I'd go with the wiki's suggestion. The city's paths in the parks are multi-use except where cycles are signed no cycling. That was arrived at with the help of a city official responsible for cycling when asked the question about Apollo Crater Park. If you look at the official city map at Apollo Crater Park the city official cycling map shows some paths as cycle paths and some are not, yet on the ground there is very little difference, possibly some are very slightly wider. Welcome to OSM by the way. Cheerio John On 28 April 2012 09:48, Daniel Marques rj.dan...@gmail.com wrote: Hi I would like to introduce myself to the group. I currently live in Kanata, I've been mapping trails and paths in Kanata while biking, as many other users do as hobby, I thought it would be interesting to add those unmapped trails somewhere and I found OSM project. Basically I'd like to check if I'm doing it all right. Talking about mixed paths where both walking and biking is allowed, I was following the same descriptions of nearby paths, i.e. highway=footpath; bicycle=yes, but I found in the wiki that it is better set them as highway=path, bicycle=yes, foot=yes. That means updating several existing paths. Is that okay? Also we have some recognized mountain bike trails as result of a great work carried by the Ottawa Mountain Bike Association. I'd like to add trail names and other mtb related info. Finally I'm adjusting some natural features like green areas that had been reduced due development, new construction sites and clear cuts. Some areas already have streets and houses mapped, some are recognisable on bing aerial images but some aren't. I'm just concerned about the lack of official source, since in some cases the source is what I see. I appreciate any help or guideline. http://www.openstreetmap.org/user/dfmarx/edits http://www.openstreetmap.org/user/dfmarx/traces Cheers, Daniel Marques ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Notice à suivre pour les imports
Bonjour à tous, Les guideslines sur les imports (http://wiki.openstreetmap.org/wiki/Import/Guidelines ) vont plus loin en préconisant de ne pas utiliser le tag source pour mentionner l'origine des données. - Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source http://wiki.openstreetmap.org/wiki/Key:source=* tag. - Ce choix est motivé par : - l'usage du compte OSM créé pour l'import afin de donner des informations sur la source, les outils, le lien vers une page du wiki. Le nom même du compte peut indiquer la source. - la permanence de l'enregistrement des modifications effectuées à l'aide du compte d'import. - le souci de ne pas charger la base de données de la carte OSM sachant que l'historique des modifications est à part Pour connaitre la source d'un objet, il faut consulter l'historique des modifications et repérer le compte qui a créé l'objet. Cela me laisse perplexe sur la visibilité qu'OSM veut donner à ses sources. Autant citer la liste de tous les organismes ayant fourni des données dans les conditions générales d'utilisation d'OSM ou dans une page Remerciements du wiki. En tant que contributeur, le tag source me parait une indication utile sur la qualité d'un objet. Si je constate une anomalie, je peux contacter la source (cf les monuments historiques mal localisés) ou l'auteur de l'import. Le mouvement Opendata amorcé en France va générer des imports de données. Il me parait important que la communauté OSM s'accorde sur des règles et pratiques pour ces projets d'import. Librement Christophe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Pour que ce soit cohérent, il faudrait alors un seul compte utilisateur par source, et seul ce compte pourrait importer des données. Est-ce à dire qu'on ne peut plus importer de données venant du cadastre par exemple, et seulement compter sur les administrations pour qu'elles procèdent elles-mêmes aux imports ? Jusqu'à présent, elles ne peuvent pas le faire car elles ne sont pas financées pour le faire. La règle énoncée me semble totalement anticollaborative. Mentionner la source est une bonne chose. En attendant, cela veut dire que si quelqu'un importe une source, il doit utiliser un compte utilisateur séparé pour chaque source ? Et s'abstenir totalement de fusionner d'autres données ou dédoublonner les données importées avec les données existantes, à charge ensuite pour lui d'utiliser un autre compte pour faire le nettoyage ? Le risque est alors de trouver dans la base des quantités énormes de doublons, incohérents entre eux. Il y a pourtant un autre outil pour le suivi : les groupes de modification, qui sont conservés aussi dans les historiques et peuvent mentionner la source utilisée. Utiliser plusieurs comptes ne peut qu'apporter des tonnes de problèmes, par l'impossibilité de fusionner les données en doublon (et la base contiendra bien plus de pollution que les chaines du tag source=* !!!). Il suffit d'indiquer la source dans le commentaire du groupe de modification. Plusieurs comptes c'est inutile, et le risque d'utiliser le mauvais compte pour certaines modifs est grand (d'autant qu'il n'est pas aisé de le faire dans les éditeurs actuels). Cette règle est ridicule, contre-productive, anti-collaborative, et produira bien plus d'effets indésirables ! Je milite plutôt pour les commentaires des groupes de modification, si on veut arrêter d'utiliser les tag source=*. Le 28 avril 2012 12:41, isnogoud os...@free.fr a écrit : Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source=* tag. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[forum-osm-fr]cr�ation de trace GPS
Le message suivant de Sleyb: ## bonjour je cherche un site ou un soft avec le quel je pourrai faire des traces GPX avec le fond de carte openstreeet.. es ce quelqu'un aurai ça sous la main merci a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose erreur de validation no translation
Le 25 avril 2012, Fabien a écrit : Bonjour, En essayant de corriger les erreurs osmose dans Marseille je suis tombé sur ce point [1]. II annonce un problème de traduction mais ne correspond à aucun noeud réel dans la base OSM. J'ai regardé les bâtiments autour mais je ne vois pas à quoi cela peut être lié. Quelqu'un a une idée ? C'est un petit souci dans le frontend d'osmose. Si ton navigateur est configuré en anglais par défaut (ou du moins, plus important que le français) et que l'analyse ne retourne pas de traduction anglaise pour le sous-titre d'une erreur, alors le frontend met no translation dans la version en anglais. Si ton navigateur a le français par défaut, ça devrait afficher correctement la version en français. J'ai corrigé le frontend pour qu'il prenne un des sous-titres fournis par l'analyse pour la version anglaise: tu ne devrais plus avoir ce problème maintenant :) -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Bonjour, je suis assez d'accord avec Pieren avec nuance sur je tag source qui facilite l'appréciation des données lors du mapping. De plus on est si nombreux à utiliser des données via import, parfois partiels et en tous cas toujours retouchés qu'un compte dédié n'a de sens que pour des cas particuliers. Mes 0.02€ Le 28/04/12, Philippe Verdyverd...@wanadoo.fr a écrit : Pour que ce soit cohérent, il faudrait alors un seul compte utilisateur par source, et seul ce compte pourrait importer des données. Est-ce à dire qu'on ne peut plus importer de données venant du cadastre par exemple, et seulement compter sur les administrations pour qu'elles procèdent elles-mêmes aux imports ? Jusqu'à présent, elles ne peuvent pas le faire car elles ne sont pas financées pour le faire. La règle énoncée me semble totalement anticollaborative. Mentionner la source est une bonne chose. En attendant, cela veut dire que si quelqu'un importe une source, il doit utiliser un compte utilisateur séparé pour chaque source ? Et s'abstenir totalement de fusionner d'autres données ou dédoublonner les données importées avec les données existantes, à charge ensuite pour lui d'utiliser un autre compte pour faire le nettoyage ? Le risque est alors de trouver dans la base des quantités énormes de doublons, incohérents entre eux. Il y a pourtant un autre outil pour le suivi : les groupes de modification, qui sont conservés aussi dans les historiques et peuvent mentionner la source utilisée. Utiliser plusieurs comptes ne peut qu'apporter des tonnes de problèmes, par l'impossibilité de fusionner les données en doublon (et la base contiendra bien plus de pollution que les chaines du tag source=* !!!). Il suffit d'indiquer la source dans le commentaire du groupe de modification. Plusieurs comptes c'est inutile, et le risque d'utiliser le mauvais compte pour certaines modifs est grand (d'autant qu'il n'est pas aisé de le faire dans les éditeurs actuels). Cette règle est ridicule, contre-productive, anti-collaborative, et produira bien plus d'effets indésirables ! Je milite plutôt pour les commentaires des groupes de modification, si on veut arrêter d'utiliser les tag source=*. Le 28 avril 2012 12:41, isnogoud os...@free.fr a écrit : Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source=* tag. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé avec mon mobile Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, avec cquest, on a eus une discussion sur IRC avec pnorman justement. On ne peut pas dire que ça a été une discussion super plaisante mais Christian me corrigera, voila les grandes lignes: Import de sa ville locale fait correctement bien nettoyé en utilisant les connaissances locales, pas de compte particulier Serial importer de villes, compte particulier pour l'import des villes par personne. Je ne suis pas convaincue par certains des arguments avances mais on va essayer de jouer le jeu un minimum :) La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Donc je pense qu'en faisant attention la dessus ça devrait passer. Toutefois, comme il a ete fait avec Corine, des que l'on fait un import massif, il faut vraiment créer un compte particulier pour ça. Emilie Laffray On 27/04/2012 06:47, Fabien wrote: pnornam D'ailleurs il m'a répondu en demandant de mettre à jour le wiki. J'attends quand même des avis ici plus nombreux. Fabien//lists.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+b7psACgkQ7H1ne0ugLJnX5wCfWejlBFlGJmuLBHPZJOIeHxPF uEIAn21QM4rqfg4fJJ/muTcDRYMQ2oW1 =jokW -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Pour les serial importer... pnormal va me fournir les comptes qu'il a repérer. Je contacterai les contributeurs en questions afin de leur rappeler qu'il y a du travail à faire sur chaque import de cadastre: - fusionner avec l'existant: bâtiments et POI - s'assurer que la voirie est cohérente et qu'elle ne coupe pas les bâtiments qu'on ajoute La qualité doit passer avant la quantité. Le 28 avril 2012 15:20, Emilie Laffray emilie.laff...@gmail.com a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, avec cquest, on a eus une discussion sur IRC avec pnorman justement. On ne peut pas dire que ça a été une discussion super plaisante mais Christian me corrigera, voila les grandes lignes: Import de sa ville locale fait correctement bien nettoyé en utilisant les connaissances locales, pas de compte particulier Serial importer de villes, compte particulier pour l'import des villes par personne. Je ne suis pas convaincue par certains des arguments avances mais on va essayer de jouer le jeu un minimum :) La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Donc je pense qu'en faisant attention la dessus ça devrait passer. Toutefois, comme il a ete fait avec Corine, des que l'on fait un import massif, il faut vraiment créer un compte particulier pour ça. Emilie Laffray On 27/04/2012 06:47, Fabien wrote: pnornam D'ailleurs il m'a répondu en demandant de mettre à jour le wiki. J'attends quand même des avis ici plus nombreux. Fabien//lists.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+b7psACgkQ7H1ne0ugLJnX5wCfWejlBFlGJmuLBHPZJOIeHxPF uEIAn21QM4rqfg4fJJ/muTcDRYMQ2oW1 =jokW -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28 avril 2012 15:20, Emilie Laffray emilie.laff...@gmail.com a écrit : La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce lié au fait que j'ai corrigé des problèmes de géométrie un peu partout sur les frontières espagnoles ? Ce n'était pas des imports massifs, mais bien des corrections manuelles basées sur les données existantes. Pour que la carte affchée sur Layers s'affiche correctement dans tous les niveaux (c'est presque fini, sauf les municipalité en Aragon dont certaines ont plusieurs relations, chacune contenant une partie des frontières pour la même municipalité, ce que ni Osmose, ni Layers ne détectent), et les divers problèmes relevés sur Osmose (problèmes de rôles, problèmes de ways en doublons, communes non correctement fermées, et corrections demandées surt les frontières côtières pour lesquelles j'ai remplacé les frontières maritimes par les lignes côtières sur tous les niveaux sauf le niveau 2), plus des corrections mineures sur Bing. Une des communes espagnoles a un tracé assez bizarre que je n'arrive pas à faire valider dans l'état, la majeure partie de sa surface est constituée de municipalités quasi-jointives (sauf une petite bande de séparation de parfois moins de 10 mètres), ce qui donne à cette commune englobante l'allure d'un patchwork. J'ai fait tous les niveaux 4,5,6,7,8, et quelques niveaux 9 (je laisse de côté le niveau 10 qui n'est qu'à l'ébauche). De plus j'ai ajouté quelques comarques (niveau 7) J'ai fini les Canaries, il me reste quelques communes côtières près de Barcelone et Valencienne, et les communes des Baléares. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cantons administratifs
Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Bonjour, Le 28/04/2012 17:35, Philippe Verdy a écrit : Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Que ce soit côté INSEE [1] ou Wikipedia [2], je vois surtout le canton évoqué comme subdivision à vocation électorale : le canton comme territoire d'élection d'un conseiller général. Si tu as des références à fournir, elles sont bienvenues. Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Ce que tu dis me fait plutôt penser aux pseudo-cantons de l'INSEE, à vocation statistique, et pour lesquels le découpage s'arrange pour que chaque commune soit inscrite dans un et un seul pseudo-canton : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton-ou-ville.htm Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? C'est en effet l'usage d'utiliser des valeurs entières pour le tag admin_level. Le principe dérape parfois un peu : http://taginfo.openstreetmap.org/keys/admin_level#values Au moment où, dans OSM, le niveau admin_level=7 a été attribué aux arrondissements départementaux [3], les niveaux 6 (département) et 8 (communes) étaient largement établis et non discutés. Le canton n'a pas été considéré comme concurrent pour ce niveau, vu sous l'angle de circonscription électorale (plus qu'administrative), car placé tantôt au dessus des communes (en zone rurale), tantôt en dessous ou à cheval (en urbain), ce qui rend sa place dans une pyramide comme celle des étages d'admin_level hasardeuse : 7 ? 8 ? 8 bis ? 9 ? Le choix de boundary=political, qui pré-existait sur le wiki [4], s'est fait dans ce contexte. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton.htm [2] : http://fr.wikipedia.org/wiki/Administration_territoriale_de_la_France#4_055_cantons [3] : http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033514.html [4] : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit : La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. (...) Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Il n'y a pas de subdivision politique en France qui ne soit pas administrative. Les cantons électoraux sont plutôt appelés aujourd'hui circonscriptions électorales. L'Insee fait un regroupement des communes en cantons entiers, quitte à y inclure ce qu'il appelle des fractions cantonales pour les communes couvertes par plusieurs cantons. Ils n'ont rien de statistiques puisqu'ils continuent à avoir un rôle administratif pour les services de l'Etat ne dépendant pas des collectivités locales (essentiellement la police et la gendarmerie, l'administration fiscale, puisque concernant l'éducation ce sont les académies qui se subdivisent selon les régions, départements et communes, les communes pouvant définir des zones aussi pour l'enseignement public de la carte scolaire, ou d'autres regroupements intercommunaux maintenant aussi au sein de leur EPCI). L'outil statistique c'est la fraction cantonale, pas le canton qui reste un niveau administratif (de l'Etat et non des collectivités locales). Le 28 avril 2012 18:19, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 28/04/2012 17:35, Philippe Verdy a écrit : Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Que ce soit côté INSEE [1] ou Wikipedia [2], je vois surtout le canton évoqué comme subdivision à vocation électorale : le canton comme territoire d'élection d'un conseiller général. Si tu as des références à fournir, elles sont bienvenues. Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Ce que tu dis me fait plutôt penser aux pseudo-cantons de l'INSEE, à vocation statistique, et pour lesquels le découpage s'arrange pour que chaque commune soit inscrite dans un et un seul pseudo-canton : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton-ou-ville.htm Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? C'est en effet l'usage d'utiliser des valeurs entières pour le tag admin_level. Le principe dérape parfois un peu : http://taginfo.openstreetmap.org/keys/admin_level#values Au moment où, dans OSM, le niveau admin_level=7 a été attribué aux arrondissements départementaux [3], les niveaux 6 (département) et 8 (communes) étaient largement établis et non discutés. Le canton n'a pas été considéré comme concurrent pour ce niveau, vu sous l'angle de circonscription électorale (plus qu'administrative), car placé tantôt au dessus des communes (en zone rurale), tantôt en dessous ou à cheval (en urbain), ce qui rend sa place dans une pyramide comme celle des étages d'admin_level hasardeuse : 7 ? 8 ? 8 bis ? 9 ? Le choix de boundary=political, qui pré-existait sur le wiki [4], s'est fait dans ce contexte. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton.htm [2] : http://fr.wikipedia.org/wiki/Administration_territoriale_de_la_France#4_055_cantons [3] : http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033514.html [4] : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur plusieurs semaines des millions de points, noeuds et relations (souvent plusieurs fois à cause des conflits). Ca m'a pris un temps fou. J'ai mis les commentaires différents selon les cas. C'est très visible que ce n'était pas un travail de robot (y compris parfois des modifs en plusieurs étapes pour vérifier des étapes intermédiaires pour pouvoir les annuler facilement en cas de pépin, et en regardant le rendu Mapnik ou Mapquest, et revérfiant chaque fois avec Osmose et Layers, l'analyseur de relations, et OSM Inspector... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur plusieurs semaines des millions de points, noeuds et relations (souvent plusieurs fois à cause des conflits). Ca m'a pris un temps fou. J'ai mis les commentaires différents selon les cas. C'est très visible que ce n'était pas un travail de robot (y compris parfois des modifs en plusieurs étapes pour vérifier des étapes intermédiaires pour pouvoir les annuler facilement en cas de pépin, et en regardant le rendu Mapnik ou Mapquest, et revérfiant chaque fois avec Osmose et Layers, l'analyseur de relations, et OSM Inspector... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Effectivement, mais dans de nombreux cas, mes modifs concernaient aussi les côtes, les landuse=* (ports, forets en distinguant bien les forêts de feuillus, conifères et mixtes, prairies, vignobles, zones résidentielles), y compris la récupération des fragments CORINE quant ils rendaient la carte illisible et ajoutaient des tas de points inutiles (ne correspondant à rien sur des zones jointives ayant exactement les mêmes attributs, cas fréquent sur les forêts que j'ai pu récupérer en grand nombre quand leur géométrie était totalement cassée) et des zones naturelles (plages, réserves naturelles, zones humides). A ce sujet, Osmose continue de me forunir des tonnes de faux positifs de façon répétée (alors qu'ils sont corrigés : Analyse 1 ne donne aucune erreur, ni Layers, et pourtant Osmose insiste tous les 3(4 jours pour mettre une étiquette à l'extrémité de TOUTES les limites communes des ways de frontières de toutes les municipalités (niveau 8) à l'intérieur des provinces (niveau 6) ou commautés autonome (niveau 4) : ces étiquettes d'erreur sont toutes fausses et mentionnent sans arrêt des points qui ne font nulle part partie des ways des frontières. J'ai tenté de signaler ces points en faux positifs, sans succès : ils reviennent elors que tout est bon. Même chose en les marquant comme corrigés (ils reviennent aussi 3 jours plus tard). Cela ne facilite pas du tout les corrections car cela cache les vraies erreurs, et il faut à chaque fois remarquer comme corrigé des centaines de points inutiles pour la même relation (que j'ai revérifiés dans Layers et avec le lien Analyse 1 d'Osmose qui ne signale aucune erreur pourtant). Il me semble donc qu'Osmose a des problèmes à calculer ses géométries. Ou bien je me demande si ce n'est pas un bogue d'Osmose (qui le fait aussi en Italie, en Allemagne, au Royaume-Uni, en Suisse...). On dirait qu'il ne tient pas compte des modifications effectuées dans ces pays et continue de réutiliser d'anciennes données à chaque import (comme si Osmose n'intégrait à chaque passage tous les 3 jours que les modifs effectuées en France). Osmose ne marche-t-il réellement que pour la France ? Le 28 avril 2012 19:01, Ab_fab gamma@gmail.com a écrit : Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur
Re: [OSM-talk-fr] Notice à suivre pour les imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, en effet Philippe se trompe complètement. Ce que les espagnols sont en train d'importer est un mélange de bâtiments, de landuse. La plupart des limites administratives sont déjà importées depuis belle lurette. Bref encore pas mal de hors sujet avec aucun rapport ce qui se passe sans compter que l'import massif espagnol est le fait d'une seule personne pour le moment alors que la communauté espagnole est encore en train de discuter de tout ça. Emilie Laffray On 28/04/2012 18:01, Ab_fab wrote: Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. sts.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+cQGQACgkQ7H1ne0ugLJl1bQCdGMCiYIdBUE3gJB/Om4b7L1yt YfMAnj+/lREAKSlAtzNWqxrJ8NryOyr8 =pnAa -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. De plus les limites espagnoles étaient encore loin d'être finies, certes elles avaient été importées mais avec des tonnes d'erreurs de géométrie, que je suis en train de corriger (puisque cela n'a jamais été fait; si vous avez vous les cartes Layers il y a deux semaines, c'était bourré de trous à cause des erreurs de géométrie et chemins en doublons mal connectées; de plus il y manquait pas mal d'admin_center non référencé, et il y avait encore pas mal de problèmes, très visibles aussi bien dans Osmose que Layers et OSM Inspector; diverses erreurs de zones superposées, des través approximatifs aussi, plein de lignes côtières fantaisistes, et des tonnes de TODO/FIXME (depuis longtemps). Au départ je n'aurais pas fait l'Espagne si la stabilité des frontières françaises dans les Pyrénées n'était pas en jeu (car aussi il y a encore du boulot à faire dans nos montagnes. Et puis les espagnols sont moins agressifs que certains d'entre vous sur cette liste à laquelle on m'avait pourtant invité. Le 28 avril 2012 21:09, Emilie Laffray emilie.laff...@gmail.com a écrit : en effet Philippe se trompe complètement. Ce que les espagnols sont en train d'importer est un mélange de bâtiments, de landuse. La plupart des limites administratives sont déjà importées depuis belle lurette. Bref encore pas mal de hors sujet avec aucun rapport ce qui se passe sans compter que l'import massif espagnol est le fait d'une seule personne pour le moment alors que la communauté espagnole est encore en train de discuter de tout ça. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 19:10, Vincent de Chateau-Thierry a écrit : Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent Bonsoir, C'est quand même Philippe qui a raison administrativement parlant! Cela est une certitude. En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Soit 8 niveaux! Le problème est qu'à vouloir à tout prix faire de l'international et se plier aux systèmes anglophones (pour ne pas dire américain) on en oublie notre propre structure. Seuls les 5 premiers et le 7° sont impératifs du point de vue de la loi le 6° étant fortement recommandé dans un souci de rationalisation des moyens. Les points 5 et 6 peuvent se fusionner mais ce n'est absolument pas une vérité. Le point 8 n'a que peu d'intérêt car ce sont des structures consultatives. Maintenant si on veut s'amuser avec les juridictions je peux vous donner du plaisir avec l'ancien régime. La vous aurez des inclusions exclusions en pagaille dans les relations. Vous aurez une structure différente par type de sujet couvert: La justice, n'est pas la même selon que nous sommes au niveau seigneurial ou royal. Mêmes choses pour les impôts déclinés chacun avec leur zone géographique. Amusez-vous avec le rattachement des paroisses à leur évêché. Amusez-vous aussi avec les provinces et les parlements. Il est assez rare de voir toutes ces juridictions coller exactement les unes avec les autres. Et nous ne parlons pas de date car à c'est un individu qui avait le privilège donc selon le pouvoir royal tout peut changer d'une période à l'autre. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: *J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM.* Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import des points de contact du réseau postal français
Bonsoir, Pour faire suite à la discussion sur les points libérés par La Poste [1], la page de visualisation : http://osm.vdct.free.fr/postes/index.html permet désormais d'éditer les points. J'ai du faire quelques choix pour les tags, les voici : * nom du tag ref : ref:FR:LaPoste * nom du tag name : c'est name et non post_office:name. La valeur est celle de la source, modulo le passage en minuscules hors initiales, et le remplacement de 'A' par 'Annexe', et de 'PAL' par 'Principal'. * tag post_office:type : il n'est pas renseigné pour les bureaux classiques. Il vaut 'post_annex' pour les Agences Postales Communales, et 'post_partner' pour les Relais Poste Commerçants. * un tag note compile, lorsque renseignés dans la source, les items complement_adresse,adresse et lieu_dit. L'idée est de proposer une aide à la géolocalisation avec ces infos. Mais une fois le point correctement placé, ne pas hésiter à supprimer ce tag. * les tags des services disponibles sont tous de la forme tag nommant le service='yes'. Initialement, une proposition était d'utiliser amenity=copy_facility pour les photocopies, mais amenity est déjà pris pour...amenity=post_office ! * pas de tag pour le service monnaie de Paris faute de proposition. Il est toujours temps, si vous êtes inspirés :-). L'identifiant des bureaux de poste permettra le cas échéant de propager le tag le moment venu. * telephone : j'ai laissé finalement les numéros courts, partant du principe qu'ils font partie de la source et que nous avons un tag pour les intégrer. Pour les numéros classiques, je n'ai pas procédé à un formatage, c'est le numéro brut tel que dans la source, contrairement à ce que préconise la page http://wiki.openstreetmap.org/wiki/Phone . Sur les 17100 bureaux proposés dans la source, seuls 15944 sont disponibles à l'import. Les autres n'ont pas, dans la source, de coordonnées lon/lat. Ils disposent néanmoins d'une adresse, il est donc possible de les importer manuellement. Pour rappel la page du wiki qui synthétise le sujet (et qui n'est pas 100% raccord avec ce mail) : http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr/Import_des_points_de_contact_postaux L'interface vous permet de marquer un point importé, en distinguant le type d'import opéré. L'idée est de pouvoir produire des stats par la suite, voire de visualiser les points selon le type de traitement. Toutes les suggestions bienvenues. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2012-April/042797.html et suivants ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : [Talk-fr] Notice à suivre pour les imports
Le 28 avril 2012, Romain Mehut a écrit : Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM. Romain Merci Romain pour ta concision. Pour plusieurs, nous parcourons plusieurs listes de distribution et apprécions de pouvoir suivre simplement la discussion. Pour rappel, lorsque nos commentaires portent sur un point précis d'un long texte, la règle usuelle sur les groupes de discussion est de recopier cette partie du texte et la commenter ensuite. Pour ceux qui veulent consulter l'historique de la discussion, il est toujours possible de retourner sur le site http://lists.openstreetmap.org/listinfo/talk-fr . Pierre De : talk-fr-requ...@openstreetmap.org talk-fr-requ...@openstreetmap.org À : talk-fr@openstreetmap.org Envoyé le : Samedi 28 avril 2012 17h02 Objet : Lot Talk-fr, Vol 69, Parution 147 - Mail transféré - Envoyez vos messages pour la liste Talk-fr à talk-fr@openstreetmap.org Pour vous (dés)abonner par le web, consultez http://lists.openstreetmap.org/listinfo/talk-fr ou, par email, envoyez un message avec 'help' dans le corps ou dans le sujet à talk-fr-requ...@openstreetmap.org Vous pouvez contacter l'administrateur de la liste à l'adresse talk-fr-ow...@openstreetmap.org Si vous répondez, n'oubliez pas de changer l'objet du message afin qu'il soit plus spécifique que Re: Contenu du digest de Talk-fr... Thèmes du jour : 1. Re: Cantons administratifs (Vincent de Chateau-Thierry) 2. Re: Notice à suivre pour les imports (Philippe Verdy) 3. Re: Notice à suivre pour les imports (Emilie Laffray) 4. Re: Notice à suivre pour les imports (Philippe Verdy) 5. Re: Cantons administratifs (Yannick VOYEAUD) 6. Re: Notice à suivre pour les imports (Romain MEHUT) Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent Effectivement, mais dans de nombreux cas, mes modifs concernaient aussi les côtes, les landuse=* (ports, forets en distinguant bien les forêts de feuillus, conifères et mixtes, prairies, vignobles, zones résidentielles), y compris la récupération des fragments CORINE quant ils rendaient la carte illisible et ajoutaient des tas de points inutiles (ne correspondant à rien sur des zones jointives ayant exactement les mêmes attributs, cas fréquent sur les forêts que j'ai pu récupérer en grand nombre quand leur géométrie était totalement cassée) et des zones naturelles (plages, réserves naturelles, zones humides). A ce sujet, Osmose continue de me forunir des tonnes de faux positifs de façon répétée (alors qu'ils sont corrigés : Analyse 1 ne donne aucune erreur, ni Layers, et pourtant Osmose insiste tous les 3(4 jours pour mettre une étiquette à l'extrémité de TOUTES les limites communes des ways de frontières de toutes les municipalités (niveau 8) à l'intérieur des provinces (niveau 6) ou commautés autonome (niveau 4) : ces étiquettes d'erreur sont toutes fausses et mentionnent sans arrêt des points qui ne font nulle part partie des ways des frontières. J'ai tenté de signaler ces points en faux positifs, sans succès : ils reviennent elors que tout est bon. Même chose en les marquant comme corrigés (ils reviennent aussi 3 jours plus tard). Cela ne facilite pas du tout les corrections car cela cache les vraies erreurs, et il faut à chaque fois remarquer comme corrigé des centaines de points inutiles pour la même relation (que j'ai revérifiés dans Layers et avec le lien Analyse 1 d'Osmose qui ne signale aucune erreur pourtant). Il me semble donc qu'Osmose a des problèmes à calculer ses géométries. Ou bien je me demande si ce n'est pas un bogue d'Osmose (qui le fait aussi en Italie, en Allemagne, au Royaume-Uni, en Suisse...). On dirait qu'il ne tient pas compte des modifications effectuées dans ces pays et continue de réutiliser d'anciennes données à chaque import (comme si Osmose n'intégrait à chaque passage tous les 3 jours que les modifs effectuées en France). Osmose ne marche-t-il réellement que pour la France ? Le 28 avril 2012 19:01, Ab_fab gamma@gmail.com a écrit : Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 22:59, Yannick VOYEAUD a écrit : C'est quand même Philippe qui a raison administrativement parlant! Cela est une certitude. En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Soit 8 niveaux! Le problème est qu'à vouloir à tout prix faire de l'international et se plier aux systèmes anglophones (pour ne pas dire américain) on en oublie notre propre structure. En l'occurrence, le modèle de tags qui décline les valeurs d'admin_level n'a rien d'international, au contraire : à chaque pays de piocher autant de niveaux que nécessaire pour décrire ses découpages administratifs, qu'ils soient complets ou partiels en terme de couverture. Après, d'un pays à l'autre, il peut y avoir des conventions communes, comme celle qui affecte la valeur 8 d'admin_level au niveau local. Elle est d'ailleurs antérieure à OSM. Seuls les 5 premiers et le 7° sont impératifs du point de vue de la loi le 6° étant fortement recommandé dans un souci de rationalisation des moyens. Les points 5 et 6 peuvent se fusionner mais ce n'est absolument pas une vérité. Le point 8 n'a que peu d'intérêt car ce sont des structures consultatives. Concernant le statut des cantons, qu'ils soient un découpage administratif, soit (et s'il y a de la littérature là-dessus, ça m'intéresse). Le souci est pour le passage de la réalité à une modélisation où les niveaux sont imbriqués, comme c'est le cas avec les niveaux administratifs taggués en admin_level. Le canton pouvant aussi bien englober plusieurs communes (donc inférieur au niveau 8) qu'être une portion de commune (donc supérieur au niveau 8), il est impossible de le placer à un niveau constant dans la pyramide administrative une fois modélisée. D'où, compte tenu de son usage de circonscription électorale, le choix d'en faire une couche à part, hors pyramide admin, avec une valeur du tag boundary qui n'est pas administrative. Qu'on torde la réalité pour la faire entrer dans notre modèle, c'est un fait. Mais ça permet (de mon point de vue) une modélisation de la notion de canton plus claire : on définit le canton pour lui même, et non relativement à des communes, ce qui serait un casse-tête. Par suite la saisie (côté contributeur) et l'exploitation (côté consommateur) sont facilitées, c'est toujours ça. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
D'une part il fallait repérer ce seul mot dans un plus ancien message qui n'est pas celui auquel j'ai répondu en copiant justement une phrase d'Emilie. Elle parlait de données en nombre en Espagne, surtout des multipolygones et c'est uniquement là-dessus que j'ai répondu en citant justement sa phrase, car le sujet avait déjà dévié avant moi de son premier mesage dont la porée était toutefois bien plus générique que les seuls imports de bâti mais traitait tout import en général. Elle a évoqué un point particulier et c'est là-dessus que j'ai répondu, en restant justement dans son sujet. Arrêtez d'être plus pointilleux qu'elle. Je suis resté dans son sujet. Merci. Le 28 avril 2012 23:02, Romain MEHUT romain.me...@gmail.com a écrit : Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28 avril 2012 22:59, Yannick VOYEAUD yann...@voyeaud.org a écrit : En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Tu oublies les arrondissements municipiaux entre 7 et 8 ici, qui sont dans la hiérarchie. Et non les communautés de communes (ou de façon plus générale les EPCI) ne sont pas des niveaux administratifs. En plus ces EPCI ne sont pas des subdivisions des cantons, ni des arrondissements départementaux et il arrive même qu'on ait des EPCI à cheval sur plusieurs départements ou régions. Les EPCI ne respectent pas la hiérarchie. De même les cantons ne suivent pas toujours les communes entières puisuq'il y a des fractions cantonnales (l'Insee donne une liste exhaustive des communes coupées en plusieurs fractions cantonales, chacune dans un canton différent, sachant aussi qu'une commune fractionnée peut avoir une fraction cantonale dans un canton qui regroupe d'autres communes limitrophes toutes entières). Les EPCI ne suivent pas du tout la hiérarchie administrative. Ce sont les communes elles-mêmes qui décident de s'associer ou non, la loi leur imposant maintenant de créer des territoires sans enclaves ni exclaves, mais cela n'a pas toujours été le cas et il reste des EPCI avec enclaves/exclaves. Ce qu'on appelait classiquement canton (depuis la mise en place de l'administration de la France par Napoléon), c'était la subdivision des arrondissements, quand les cantons respectaient les limites communales et découpaient exactement les arrondissements. Ces cantons persistent aujourd'hui effectivement dans les bases Insee aussi. Les canton actuels utilisés aux fins électorales ne s'appellent plus cantons mais circonscriptions, même si dans l'usage courant on parle encore d'élections cantonales (on devrait dire élections des conseillers généraux). Il y a plusieurs types de circonscriptions selon ceux pour qui on vote : les circonscriptions électorales pour les conseils généraux, pour les députés et pour le sénat, et pour les députés européens sont différentes (il y a d'autres circonscriptions pour des scrutins non universels, tels que les chambres professionnelles). Mais en rien ces circonscriptions ne sont des divisions administratives (un redécoupage électoral n'affecte en rien les services de l'Etat comme la police ou la gendarmerie au sein des cantons traditionnels). Ce sont ces cnatons traditionnels et non les circonscriptions électorales très changeantes qui sont référencées comme base et dans les noms de certains EPCI. Ces circonscritions ne sont pas non plus des subdivisions politiques. Et puis tu oublies d'autres regroupements: les pays (au sein des départements, certains étant à cheval sur plusieurs arrondissements mais incluant des communes entières), et pays loi Voynet (plus grand et pouvant inclure des communes sur plusieurs départements et régions) : ces regroupements sont appuyés par les EPCI, l'unité de base étant la commune entière, pas le canton administratif (historique) ni une circonscription électorale (qui évolue à chaque élection uniquement sur des bases de représentation équitable de la population sans tenir compte des subdivisions administratives ou historiques actuelles, sur la base des données de recensement de population, pour qu'il y ait à peu près le même nombre de citoyens, et non d'habitants, représentés par chaque élu à chaque élection). Les circonscriptions électorales sont faites selon la loi électorale et selon le mode de scrutin (avec ou sans proportionelle, un mode proportionnel nécessitant d'agrandir les circonscriptions pour regrouper plusieurs sièges d'élus dans une même circonscription par rapport au mode majoritaire). Les circonscriptions ne servent qu'aux élections, elles ne créent pas de subdivisions administratives. Et ne sont pas politiques non plus. Les cantons sont en revanche toujours des subdivisions administratives (même si ce ne sont pas des collectivités locales, ils émanent directement de l'Etat via les préfets). Enfin on peut parler d'autres découpages de la France (non directement administratifs) : le découpage des régions militaires, celui des régions maritimes, celui des juridictions, la carte hospitalière, les académies et la carte scolaire, la sécurité sociale, les zones d'emploi, etc. Chaque ministère crée et gère son découpage pour ses services aujourd'hui (d'autant plus vite que l'Etat veut en réduire le nombre, ferme des hopitaux, écoles), et il en est de même depuis que les communes (et autres collectivités locales) ont transféré des compétences vers leur EPCI pour les services socio-médicaux et équipements/services culturels ou sportifs, l'assainissement, les ordures ménagères, la protection de l'environnement, l'urbanisme, la voirie et les plans de
Re: [OSM-ja] OpenStreetMap国際カンファレンス SotM のプレゼンテーション公募
としです。 SotMのプレゼンテーション公募がいよいよ締切近づいております。 4月30日(世界標準時)までですので、くれぐれもお忘れなく！！ 個人的には、自作GPSロガーネタで応募したのですが、 もう一つ、地域OSMコミュニティの活動として、 関西OSMコミュニティの活動についても、簡単に発表できないかなと 思っていますが、いかがでしょうか＞関西OSMな皆さま 私個人としては、ライトニングトーク枠が良いかなと思いますが、 何かありましたらお知らせ下さい。 特段のご異論がなさそうでしたら、日本時間で４月３０日の２１時頃に ライトニングトーク枠で申し込もうとおもいます。 ではこれにて。 2012年4月26日11:20 FURUHASHI Taichi mapconcie...@gmail.com: talk-ja のみなさま： 古橋＠SotM2012実行委員会/OSMFJです。 SotMのプレゼンテーション公募がいよいよ締切近づいております。 4月30日(世界標準時)までですので、くれぐれもお忘れなく！！ 日本人の場合、日本語での発表もできます（但し、プレゼン資料と申込は英語でお願いします）。 http://www.stateofthemap.org/ja/call-for-presentations-ja/ 応募できるタイプは次の５種類です。 【Talk】 一般発表：1つの発表で、質疑応答込みで20分です。 【Short Talk】 ショートトーク：アイディアを発表するための短い発表（10分以下）です。 【ライトニングトーク】 ライトニングトーク：5分の簡単な発表です（あとで申し込むこともできます。） 【パネルディスカッション】 パネルディスカッション：パネラーおよび聴衆と議論します。 【ワークショップ】 ワークショップ：OSMer達によって詳しいチュートリアルを行うための2時間（必要であればそれ以上）のセッションです。 引き続き、SotM に向けたイベント情報を発信してまいります。 詳細についてはウェブサイトを御覧ください。 http://www.stateofthemap.org/ja/ Facebook でも、告知用の公開グループを立ちあげております。 なかなかMLでは質問しづらい場合、こちらもご利用ください。 https://www.facebook.com/groups/374749185877455/ どうぞよろしくお願いいたします。 -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap F. Japan with sinsai.info ## Director of the OSGeo F. Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## TEL/SkypeTwitterLIFB: 070-6401-5963 / mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan/UAV Shop: http://gpsconcierge.jp 備考欄「古橋紹介」記載で5%OFF ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-GB] UK Tagging Guideline - wiki page proposals
On 21/04/12 00:13, Andy wrote: Just a couple of quick notes: * The cycle path section is a bit misleading as it stands. The tagging you have shown is for standalone paths (i.e. mapped separately from a road); the majority of cycle paths in the UK are on the side of a road and thus should be tagged something like highway=primary,secondary..., cycleway=track, segregated=yes/no. I've copied the relevant section onto my user page and altered it: https://wiki.openstreetmap.org/wiki/User:Spark * I would prefer to see the 'UK Classic vs Global' stuff taken out - these are the *UK* guidelines and hence the best/commonest practice in the UK should be given. Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb I should have read these tagging guides before. I have tried to map local cycle paths along the side of the road by creating a way parallel to the road and tagging it as a highway=cycleway. Do I understand from the above that it is better practice to simply add a cycleway=track tag to the main highway? My excuse for doing it via a separate way is that I was copying somebody else's practice and I could see that his way of doing it resulted in nice rendering on the Cycle Map which can be accessed from the main map page. Bogus Zaba ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Tagging Guideline - wiki page proposals
In my opinion, the cycleway=track method is much better - it's easier to map, gives a cleaner and more accurate rendering, and is more representative of what's on the ground. Routing works much better this way too. I would use a separate way and highway=cycleway when the cycle path is any significant distance away from the edge of the road. Cheers, Andy On Apr 28, 2012 9:44 a.m., Bogus Zaba bog...@bogzab.plus.com wrote: On 21/04/12 00:13, Andy wrote: Just a couple of quick notes: * The cycle path section is a bit misleading as it stands. The tagging you have shown is for standalone paths (i.e. mapped separately from a road); the majority of cycle paths in the UK are on the side of a road and thus should be tagged something like highway=primary,secondary...**, cycleway=track, segregated=yes/no. I've copied the relevant section onto my user page and altered it: https://wiki.openstreetmap.**org/wiki/User:Sparkhttps://wiki.openstreetmap.org/wiki/User:Spark * I would prefer to see the 'UK Classic vs Global' stuff taken out - these are the *UK* guidelines and hence the best/commonest practice in the UK should be given. Cheers, Andy __**_ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-gbhttp://lists.openstreetmap.org/listinfo/talk-gb I should have read these tagging guides before. I have tried to map local cycle paths along the side of the road by creating a way parallel to the road and tagging it as a highway=cycleway. Do I understand from the above that it is better practice to simply add a cycleway=track tag to the main highway? My excuse for doing it via a separate way is that I was copying somebody else's practice and I could see that his way of doing it resulted in nice rendering on the Cycle Map which can be accessed from the main map page. Bogus Zaba __**_ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-gbhttp://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Tagging Guideline - wiki page proposals
I'd only use cycleway=track if there's a track on both sides, otherwise I use cycleway:left=track or cycleway:right=track, as appropriate. I also add a highway=cycleway alongside, because some applications prefer one method, some the other, and there's little harm having both (in my view). cycleway=track wasn't rendered on the cycle layer until fairly recently, and one-sided tracks _aren't_ rendered. So if you want them to show on the cycle layer, you need to create a separate highway=cycleway (or highway=footway|path+bicycle=yes|designated). Richard On Sat, Apr 28, 2012 at 9:47 AM, Bogus Zaba bog...@bogzab.plus.com wrote: On 21/04/12 00:13, Andy wrote: Just a couple of quick notes: * The cycle path section is a bit misleading as it stands. The tagging you have shown is for standalone paths (i.e. mapped separately from a road); the majority of cycle paths in the UK are on the side of a road and thus should be tagged something like highway=primary,secondary...**, cycleway=track, segregated=yes/no. I've copied the relevant section onto my user page and altered it: https://wiki.openstreetmap.**org/wiki/User:Sparkhttps://wiki.openstreetmap.org/wiki/User:Spark * I would prefer to see the 'UK Classic vs Global' stuff taken out - these are the *UK* guidelines and hence the best/commonest practice in the UK should be given. Cheers, Andy __**_ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-gbhttp://lists.openstreetmap.org/listinfo/talk-gb I should have read these tagging guides before. I have tried to map local cycle paths along the side of the road by creating a way parallel to the road and tagging it as a highway=cycleway. Do I understand from the above that it is better practice to simply add a cycleway=track tag to the main highway? My excuse for doing it via a separate way is that I was copying somebody else's practice and I could see that his way of doing it resulted in nice rendering on the Cycle Map which can be accessed from the main map page. Bogus Zaba __**_ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-gbhttp://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Tagging Guideline - wiki page proposals
On 22 April 2012 18:34, Peter Rounce pe...@rounce.me.uk wrote: http://wiki.openstreetmap.org/wiki/Talk:United_Kingdom_Tagging_Guidelines_Consultation Achadwick's RoW table section Byway Open to All Traffic column motor_vehicle tag row I believe this should be 'yes' instead of '~'. Wouldn't that just be a restatement of the inherited value? IMO, the table's B-O-A-T/motor_vehicle cell has the right suggestion, namely leave it blank on objects in the database, because it's already implied by the vehicle=yes. Leaving motor_vehicle=* unstated on an OSM object means that data consumers should use whatever's explicitly set on on the vehicle=* tag for motor_vehicle access to that object. This is the way OSM access tag inheritance works normally, and in this specific case yields the value yes for motor vehicles. from.. http://josm.openstreetmap.de/wiki/Presets/EnglandWalesRightsOfWay !-- Rationale: the Road Traffic Regulation Act 1984, section 15(9)(c) states that a BOAT is [...] a highway over which the public have a right of way [access=yes] for vehicular and all other kinds of traffic but which is used by the public mainly for the purpose for which footpaths and bridleways are used [access=designated]. Bicycles were probably using bridleways commonly by 1984, so they are designated. -- In other words, motor vehicles, and indeed any kind of vehicle including the pony-and-trap, have a legally enshrined right of way in the relevant legislation. They are not *specifically* named by mode in law though, so they don't get the =designated. The dodgy argument in the comment and in the table is the one in favour of =designated for bicycles. I'd love some feedback on that; perhaps it should be no greater a degree of official access than that for bridleways (bicycle=yes). However, BOATs are generally better built for pedal cycles than are bridleways, and council signage and websites favour lighter vehicle usage over heavier for BOATs. Dunno if that, and the legal-historical argument, is really enough to deserve bicycle=designated for BOATs though. Criticism welcome, I'm still happy to maintain the presets in line with any new page which emerges. -- Andrew Chadwick ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-us] Waterway directionality in drainage canals
It's the standard to draw a waterway in the direction of flow. I've questioned this several times, but it's an ingrained default. My question is more specific: what happens to a drainage canal that reverses direction? I offer the Everglades and surrounding agricultural land as an example. There are huge water conservation areas that store water. When it rains, gates are closed and opened to direct water into these. During a drought, gates send water back out into the canals for local use. When there's a big storm, water will instead go directly out to sea. So there are a lot of major canals that have no fixed direction. How should these be mapped? Is there any existing scheme that can show how water flows under different conditions? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Waterway directionality in drainage canals
From: Nathan Edgars II [mailto:nerou...@gmail.com] Sent: Saturday, April 28, 2012 2:24 AM To: Tag discussion, strategy and related tools; OpenStreetMap talk-us list Subject: [Talk-us] Waterway directionality in drainage canals It's the standard to draw a waterway in the direction of flow. I've questioned this several times, but it's an ingrained default. My question is more specific: what happens to a drainage canal that reverses direction? I offer the Everglades and surrounding agricultural land as an example. There are huge water conservation areas that store water. When it rains, gates are closed and opened to direct water into these. During a drought, gates send water back out into the canals for local use. When there's a big storm, water will instead go directly out to sea. So there are a lot of major canals that have no fixed direction. How should these be mapped? Is there any existing scheme that can show how water flows under different conditions? The same issue came up with minor drainage ditches and cranberry fields here. They're used to drain sometimes and sometimes to flood the field for harvest. I came up with the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/directional for directional=* but it's abandoned. One weakness with the proposal is that unknown values are a special case of directional=no, not directional=yes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Waterway directionality in drainage canals
It's the standard to draw a waterway in the direction of flow. I've questioned this several times, but it's an ingrained default. My question is more specific: what happens to a drainage canal that reverses direction? I offer the Everglades and surrounding agricultural land as an example. There are huge water conservation areas that store water. When it rains, gates are closed and opened to direct water into these. During a drought, gates send water back out into the canals for local use. When there's a big storm, water will instead go directly out to sea. So there are a lot of major canals that have no fixed direction. How should these be mapped? Is there any existing scheme that can show how water flows under different conditions? Calling all real technical-consulting planet-oriented hydrologists: join in this conversation, please! (You never know). NE2, you might invent, then propose a newer, meant to be better because we discussed it first standard after asking that question the way you did. One way you seem to do so (NE2, though others, too) is with tags containing colons, as that has emerged in much structured tagging in a somewhat orderly way. Without deriving a dialect of it off the top of my head, that might even be a specific instance of what is known as a regular language. (We use network=US:I for Interstates, for example). Inventing a stub language like tidal=yes and barrier=marine_gate and semantics for the actual direction of the way that represents something ABOUT its flow (like seasonal or active or whatever) is real work that can be sketched on a whiteboard as an idea development methodology. It's more difficult via a channel like this digested list, but difficulties can be overcome. But after some fits and starts and people double-checking and looking over each other's shoulders and finding things that work...we have something. Considering how sane, smart growth of tags and processes whereby these evolve with real intent seems a fundamental topic. Positing something like the quick stub of brain-spew above shows how some of us are good at posing questions, some of us are good at longer-term vision or middle-building, many of us are great at mapping, and all of us can recognize these differences are strengths when our numbers speak together. (Even when it is seen that there is some spew that happens, it is the process of getting better of which I type). There really is a middle of OSM which feels quite under-built to me, at least from the perspective of California. Maybe that is just me having an early-feeling, though confident and articulate voice, or lack of finding specific more-local OSM community. I have collaborated over networked wires for many decades in many ways. This newer middle of OSM overlaps in my mind with conversation places where listening and structured whiteboard-like collaboration takes place. Let's build OSM's better middle with this in mind. I look for these conversation places myself, so I reach out a bit. I do not say how (right now), it's complex, everybody seems to have ideas and want to be listening and sorting that out is hard work and would take too long (right here). But listening areas and working groups and such are the neighborhood of what I mean. Am I unplugged-in from these? Or does our national scene (OSM in the US) largely get hashed out right here in talk-us? We seem to be lacking in coordination: there are terrific skill-sets here, and much gets done, but new focus for those laser-bolts of good methods we figured out work really well for us that can synergy and feedback-loop and leap us ahead, well, as they say, could use improvement. I do put myself out here, and yes, it feels a little bold to say this. I listen, I look for structured listening. I look for better coordination and yes, maybe even towards leadership. Leadership doesn't have to be vested in an individual, it can consist of a core of ideas that work, only as a beginning. Yes, this is hard work. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
