[OSM-talk] mobile unnamed roads and more layer
Hi, I'd like to have on my iphone or android, the Geofabrik Tools for corecting roads without names, or the fixme parts etc etc I searched for such an application but no luck. Do you know of one? Also one solution is to be able to get the layer, i have an application on iphone (OpenMaps) that let me add custom layers. Cheers, Ciprian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mobile unnamed roads and more layer
Ciprian, I am currently beta testing OSMiOS, which is almost as powerfull and flexible as JOSM, or whatever you use on your desktop. There are some limitations on it, but adding tags to an existing way (as I understand you are looking for) is one of many features supported. I have no idea when the app might be available from app store though Aun Johnsen On 29. des. 2012, at 10:00, talk-requ...@openstreetmap.org wrote: Message: 3 Date: Sat, 29 Dec 2012 13:11:22 +0200 From: ciprian niculescu cnicu...@gmail.com To: OSM Talk talk@openstreetmap.org Subject: [OSM-talk] mobile unnamed roads and more layer Message-ID: CAEMue=pf4kq5j3d6y56odu0cyscxtdvlqykcjb-jwd1aecc...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi, I'd like to have on my iphone or android, the Geofabrik Tools for corecting roads without names, or the fixme parts etc etc I searched for such an application but no luck. Do you know of one? Also one solution is to be able to get the layer, i have an application on iphone (OpenMaps) that let me add custom layers. Cheers, Ciprian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mobile unnamed roads and more layer
2012/12/29 ciprian niculescu cnicu...@gmail.com:
Hi,
I'd like to have on my iphone or android, the Geofabrik Tools for corecting
roads without names, or the fixme parts etc etc
I searched for such an application but no luck.
Do you know of one?
Also one solution is to be able to get the layer, i have an application on
iphone (OpenMaps) that let me add custom layers.
You can get the layers from Geofabrik, some are here (not sure if this
is complete, if you search the archives there is a post from Frederik
or Jochen which tells you all of them):
OSMI Geometry,
http://tools.geofabrik.de/osmi/tiles/geometry/${z}/${x}/${y}.png;,
OSMI Places, http://tools.geofabrik.de/osmi/tiles/places/${z}/${x}/${y}.png;,
OSMI Tagging,
http://tools.geofabrik.de/osmi/tiles/tagging/${z}/${x}/${y}.png;,
OSMI Highways,
http://tools.geofabrik.de/osmi/tiles/highways/${z}/${x}/${y}.png;,
OSMI Multipolygon,
http://tools.geofabrik.de/osmi/tiles/multipolygon/${z}/${x}/${y}.png;,
OSMI Addresses,
http://tools.geofabrik.de/osmi/tiles/addresses/${z}/${x}/${y}.png;,
OSMI Boundaries,
http://tools.geofabrik.de/osmi/tiles/boundaries/${z}/${x}/${y}.png;,
OSMI Water, http://tools.geofabrik.de/osmi/tiles/water/${z}/${x}/${y}.png;,
OSMI Routing,
http://tools.geofabrik.de/osmi/tiles/routing/${z}/${x}/${y}.png;,
OSMI Routing (non EU),
http://tools.geofabrik.de/osmi/tiles/routing_non_eu/${z}/${x}/${y}.png;,
Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mobile unnamed roads and more layer
On 29/12/2012 11:11, ciprian niculescu wrote:
Hi,
I'd like to have on my iphone or android, the Geofabrik Tools for
corecting roads without names, or the fixme parts etc etc
I searched for such an application but no luck.
Do you know of one?
Also one solution is to be able to get the layer, i have an application
on iphone (OpenMaps) that let me add custom layers.
You could try one of these for a noname map:
http://qa.poole.ch/
http://layers.openstreetmap.fr/
It seems they work OK on the browser on my Android phone
Or if you just want the noname layer, the first one is
http://tile.poole.ch/noname/${z}/${x}/${y}.png;.
Craig
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mobile unnamed roads and more layer
thanks to all
On Sat, Dec 29, 2012 at 2:09 PM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:
2012/12/29 ciprian niculescu cnicu...@gmail.com:
Hi,
I'd like to have on my iphone or android, the Geofabrik Tools for
corecting
roads without names, or the fixme parts etc etc
I searched for such an application but no luck.
Do you know of one?
Also one solution is to be able to get the layer, i have an application
on
iphone (OpenMaps) that let me add custom layers.
You can get the layers from Geofabrik, some are here (not sure if this
is complete, if you search the archives there is a post from Frederik
or Jochen which tells you all of them):
OSMI Geometry,
http://tools.geofabrik.de/osmi/tiles/geometry/${z}/${x}/${y}.png;,
OSMI Places,
http://tools.geofabrik.de/osmi/tiles/places/${z}/${x}/${y}.png;,
OSMI Tagging,
http://tools.geofabrik.de/osmi/tiles/tagging/${z}/${x}/${y}.png;,
OSMI Highways,
http://tools.geofabrik.de/osmi/tiles/highways/${z}/${x}/${y}.png;,
OSMI Multipolygon,
http://tools.geofabrik.de/osmi/tiles/multipolygon/${z}/${x}/${y}.png;,
OSMI Addresses,
http://tools.geofabrik.de/osmi/tiles/addresses/${z}/${x}/${y}.png;,
OSMI Boundaries,
http://tools.geofabrik.de/osmi/tiles/boundaries/${z}/${x}/${y}.png;,
OSMI Water,
http://tools.geofabrik.de/osmi/tiles/water/${z}/${x}/${y}.png;,
OSMI Routing,
http://tools.geofabrik.de/osmi/tiles/routing/${z}/${x}/${y}.png;,
OSMI Routing (non EU),
http://tools.geofabrik.de/osmi/tiles/routing_non_eu/${z}/${x}/${y}.png;,
Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[Talk-de] OSM-Podcast (Radio OSM): Die Overpass API
Hallo, in der gestern erschienen Spezialausgabe von Radio OSM, dem OSM-Podcast, reden wir mit Roland Olbricht, dem Macher der Overpass API. Aus der Beschreibung unter http://blog.openstreetmap.de/2012/12/osmde009-osm-talk-die-overpass-api/ : Briefkästen, Straßen, Abbiegevorschriften – wie diese bei OpenStreetMap erfasst und in die Datenbank eingetragen werden können, weiß der ambitionierte Mapper. Doch wie lassen sich solche Informationen gezielt wieder aus der Datenbank abfragen? In dieser Spezialausgabe des deutschen OpenStreetMap-Podcasts sprechen wir mit Roland Olbricht, dem Entwickler der Overpass API, die solche gezielten Abfragen ermöglicht und inzwischen eine wichtige Rolle für viele Programme und Dienste spielt. Roland gewährt uns dabei auch Einblicke darüber, was die “Maschinisten” des OpenStreetMap-Universums, also unsere Softwareentwickler, momentan bewegt und motiviert. Direkter Link zur Audio-Datei: http://audio.podcast.openstreetmap.de/OSMDE009.mp3 Gruß, Stephan -- sb-lis...@gmx-topmail.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] POI_tool_POIseng
Guten Tag, welche Tags werden hier ausgewertet? amenity=atm oder auch amenity=bank atm=yes Gruß Steffen --- Original Nachricht --- Absender: Martin Lux Datum: 21.12.2012 10:30 Hallo, die Studierenden im Mastermodul software engineering (GeoinformatikVermessung) der FH Mainz haben eine Webapp, beruhend auf OSM-Daten, entwickelt. Mit dieser Webapp ist es möglich ATM's (Bankautomaten) in seiner unmittelbaren Nähe zu finden und zu /ändern/. Wir befinden uns momentan in der Prototyp-Phase und bräuchten Personen, die die Webapp testen. Die Webapp ist unter folgender URL zu erreichen: http://143.93.114.104/poiseng/ Ein Onlineumfragebogen ist hier zu finden: http://de.surveymonkey.com/s/3Y79RCV http://de.surveymonkey.com/s/3Y79RCV Und unsere Facebook-Seite: http://www.facebook.com/SengProjektWS2012 p.s Wenn Daten mit der App geändert werden, werden diese in einer eigene Datenbank gespeichert. Wie eben erwähnt, handelt es sich hierbei um einen Prototyp. Möglicherweise werden später zusätzliche POI-Arten implementiert und die Datenzurückführung nach OSM sichergestellt. Vielen Dank und frohe Weihnachten Gruß Martin Lux ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapnik high res rendering
Masi Master masi-mas...@gmx.de wrote: ich hab zwar an den Schildern noch nicht rumgespielt, aber gehe davon aus, dass du neben der (Schrift-)Größe [size=10] auch die Bilddatei vergrößern (seperat in einem Bildbearbeitungsprogamm) musst. Jepp. Sind leider keine Vektorsymbole. Im Falle der Straßemnsymbole beim deutschen Stil (BundesautobahnX.png) gibt es AFAIK auch keine Vektorquelle, aus der man ein höher aufgelöstes PNG erzeugen könnte. Die meisten normalen Symbole sind aber aus Vektoricons erzeugt: Brian Quinion Icon Collection: http://www.sjjb.co.uk/mapicons/contactsheet Gruss Sven -- A strategy for rewarding artists that regulates 'copies' makes as much sense in the digital age as a strategy for controlling greenhouse gases that regulates breathing. (Lawrence Lessig) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Aggiornamento dati ortografia strade
-Original Message- From: Gianluca Boero [mailto:gianlucabo...@alice.it] Sent: venerdì 28 dicembre 2012 18:31 To: openstreetmap list - italiano Subject: Re: [Talk-it] Aggiornamento dati ortografia strade Inviterei chi fa una correzione ortografica a verificare da questo elenco (si vede molto bene) se vi sono scompensi tra maiuscole e minuscole e modificare di conseguenza i nomi delle vie come richiesto dal wiki. http://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions Il wiki però non è molto chiaro. Dice di usare la maiuscola per la iniziale di OGNI parola, ad eccezione di articoli e preposizioni. Però poi si contraddice nell'esempio dei nomi contenenti date, dove dice che il mese va scritto con iniziale minuscola. Ho già assistito a delle edit war tra chi mette i nomi comuni comuni in minuscolo e chi in maiuscolo. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pedaggio autostrade
Sarebbe interessante sapere quale esatto significato dà al termine motorway_junction un nativo/madrelingua inglese (ma temo che qui ci troviamo in un caso in cui in diverse parti del mondo dove si parla ingese il significato potrebbe essere diverso). Wikipedia inglese è molto chiaro su questo: ( Terminology - A *freeway junction* or *highway interchange* (in the U.S.https://en.wikipedia.org/wiki/United_States) or *motorway junction* (in the UKhttps://en.wikipedia.org/wiki/United_Kingdom) is a type of *road junction*, linking one motorwayhttps://en.wikipedia.org/wiki/Motorwayto another; to other roads; or sometimes to just a motorway service station https://en.wikipedia.org/wiki/Motorway_service_station (dalla pagina https://en.wikipedia.org/wiki/Motorway_junction) Volker ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dati ortografia strade
Il giorno sab, 29/12/2012 alle 12.37 +0100, Alberto Nogaro ha scritto: -Original Message- From: Gianluca Boero [mailto:gianlucabo...@alice.it] Sent: venerdì 28 dicembre 2012 18:31 To: openstreetmap list - italiano Subject: Re: [Talk-it] Aggiornamento dati ortografia strade Inviterei chi fa una correzione ortografica a verificare da questo elenco (si vede molto bene) se vi sono scompensi tra maiuscole e minuscole e modificare di conseguenza i nomi delle vie come richiesto dal wiki. http://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions Il wiki però non è molto chiaro. Dice di usare la maiuscola per la iniziale di OGNI parola, ad eccezione di articoli e preposizioni. Però poi si contraddice nell'esempio dei nomi contenenti date, dove dice che il mese va scritto con iniziale minuscola. Io la noto solo adesso la regola dei mesi e naturalmente gli scrivo in maiuscolo. Il wiki è chiaro: in maiuscolo ogni parola tranne articoli, preposizioni e nomi dei mesi. Forse è la regola che non va. :) Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dati ortografia strade
Am 29/dic/2012 um 19:22 schrieb Rattorosso floydbar...@alice.it: Io la noto solo adesso la regola dei mesi e naturalmente gli scrivo in maiuscolo. Il wiki è chiaro: in maiuscolo ogni parola tranne articoli, preposizioni e nomi dei mesi. Forse è la regola che non va. :) Mi sembra strano di scrivere i nomi in minuscolo quando contengono un mese, per esempio IV novembre, quattro in maiuscolo e novembre in minuscolo? La città credo che lo scrive in maiuscolo, ed essendo un nome mi sembra giusto, vedete qui per esempio http://www.info.roma.it/strade_dettaglio.asp?ID_indirizzi=444 Ciao Martin___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dati ortografia strade
Il giorno sab, 29/12/2012 alle 23.13 +0100, Martin Koppenhoefer ha scritto: Mi sembra strano di scrivere i nomi in minuscolo quando contengono un mese, per esempio IV novembre, quattro in maiuscolo e novembre in minuscolo? La città credo che lo scrive in maiuscolo, ed essendo un nome mi sembra giusto, vedete qui per esempio http://www.info.roma.it/strade_dettaglio.asp?ID_indirizzi=444 Via di dicembre Senza Maiuscola :) In italiano sarebbe corretto scriverlo in minuscolo ma qui non centra niente. Se la regola è che tutte le parole vanno scritte con iniziale maiuscola tranne articoli e preposizioni non c'è motivo per me di fare una eccezione per i nomi dei mesi. p.s. Hai fatto un pessimo esempio, i numeri romani non vanno bene :) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Aggiornamento dati ortografia strade
La grammatica della lingua italiana dice questo: http://it.wikipedia.org/wiki/Aiuto:Maiuscolo_e_minuscolo Egregio Rattorosso, non volermene ma dovrei correggerti nel tuo messaggio come faceva la mia Prof di Italiano con un segno rosso e blu (errore gravissimo): si dice li scrivo e non gli scrivo nel contesto della tua frase. :-) Enjoi Beppe -Messaggio originale- Da: Rattorosso [mailto:floydbar...@alice.it] Inviato: sabato 29 dicembre 2012 19:23 A: talk-it@openstreetmap.org Oggetto: Re: [Talk-it] Aggiornamento dati ortografia strade Io la noto solo adesso la regola dei mesi e naturalmente gli scrivo in maiuscolo. Il wiki è chiaro: in maiuscolo ogni parola tranne articoli, preposizioni e nomi dei mesi. Forse è la regola che non va. :) Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-lt] Adresai be gatvių
On 2012.12.29 11:21, Tomas Straupis wrote: Sveiki Lietuvoje turime būrelį adresų (mažuose kaimuose), kurie susideda tik iš kaimo pavadinimo ir numerio (tarkim „Džiuginėnų k. 7“). T.y. gatvės nėra apskritai (nei adrese, nei tame kaimelyje apskritai). Nerašyti addr:street žymos kaip ir atrodytų paprasta, bet tada turime kitą bėdą: ieškodami klaidų, negalime atskirti, kuris adresas be gatvės yra teisingas, o kuris ne. Taigi ta proga galvoju adresams, kurie realiai neturi gatvės pridėti žymą: addr:nostreet=yes Bus prieštaravimų, pasiūlymų ir pan.? Tomai, o ar būtų labai sunku padaryti tikrinimą be papildomų žymų? Kiek prisimenu, formalūs reikalavimai tam yra tokie: - namų (adresų) ne daugiau 20 = apribojimas namo numeriui; - tame kaime nėra nė vienos gatvės Aišku, čia be duombazės jau nebeišsiverstum, bet gal galima [pusiau automatu] atrinkti kaimelius, kur taikoma tokia adresavimo schema ir juose nerodyti klaidų, jog nėra gatvės pavadinimo? Nežinau, ar neužliptume ant „grėblio“ su pasikartojančiais gyvenviečių pavadinimais... P.S. beje, ar klaidų tikrintojas supras http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_relations_to_associate_house_and_street_.28optional.29 ? :-) -- Aidas Kasparas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Adresai be gatvių
o ar būtų labai sunku padaryti tikrinimą be papildomų žymų? Jei tik bus pasiūlytas patikimas mechanizmas - aš už. Kiek prisimenu, formalūs reikalavimai tam yra tokie: - namų (adresų) ne daugiau 20 = apribojimas namo numeriui; - tame kaime nėra nė vienos gatvės 1. „ 20“ - nepakankama sąlyga. 2. „Kaime nėra gatvių“: a) beveik nė vienas kaimas neturi administracinių ribų (kol nesutarsime su registrų centru, nematau galimybių tokias ribas bent kiek realiu greičiu susivesti) b) galima būtų tikrinti, ar nuo kaimo taško kažkokiu spinduliu (tarkim 2km) yra bent viena gatvė su pavadinimu, bet toks variantas netiks, nes gali būti, kad gatvė su pavadinimu realiai yra, tik ji nepažymėta (tarkim tiesiog nėra „name“ žymos). Vienas iš dalykų, kas daroma tvarkant adresus - jei randami pastatai su tarkim gatve „Baibalių g.“, tai tikėtina, kad ir gatvė greta yra „Baibalių g.“. P.S. beje, ar klaidų tikrintojas supras http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_relations_to_associate_house_and_street_.28optional.29 Ne, nesupras. Bet, kol kas, tik kelis tokius adresus ir teradau... Šito klausimo sprendimui reikėtų padaryti analizę, kaip/ar „associate“ ryšį „valgo“ kiti adresų naudotojai: mkgmap'as (garmin žemėlapiai) bei nominatimas (pagrindinis OSM adresų paieškos varikliukas). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Adresai be gatvių
Aš galvoju apie navigacijas. Dauguma įvedinėjant adresus prašo nurodyti gatvę. Jei gatvės pavadinimo nebus, arba bus kažkoks simsalabim, tokiu atveju adreso paieška komplikuojasi. Jei būtu kamo pavadinimas, tai paieška ras vieną gatvę, kas atitinka realybę. 2012.12.29 13:57, Aidas Kasparas a.kaspa...@gmc.lt rašė: On 2012.12.29 11:21, Tomas Straupis wrote: Sveiki Lietuvoje turime būrelį adresų (mažuose kaimuose), kurie susideda tik iš kaimo pavadinimo ir numerio (tarkim „Džiuginėnų k. 7“). T.y. gatvės nėra apskritai (nei adrese, nei tame kaimelyje apskritai). Nerašyti addr:street žymos kaip ir atrodytų paprasta, bet tada turime kitą bėdą: ieškodami klaidų, negalime atskirti, kuris adresas be gatvės yra teisingas, o kuris ne. Taigi ta proga galvoju adresams, kurie realiai neturi gatvės pridėti žymą: addr:nostreet=yes Bus prieštaravimų, pasiūlymų ir pan.? Tomai, o ar būtų labai sunku padaryti tikrinimą be papildomų žymų? Kiek prisimenu, formalūs reikalavimai tam yra tokie: - namų (adresų) ne daugiau 20 = apribojimas namo numeriui; - tame kaime nėra nė vienos gatvės Aišku, čia be duombazės jau nebeišsiverstum, bet gal galima [pusiau automatu] atrinkti kaimelius, kur taikoma tokia adresavimo schema ir juose nerodyti klaidų, jog nėra gatvės pavadinimo? Nežinau, ar neužliptume ant „grėblio“ su pasikartojančiais gyvenviečių pavadinimais... P.S. beje, ar klaidų tikrintojas supras http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_relations_to_associate_house_and_street_.28optional.29 ? :-) -- Aidas Kasparas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Adresai be gatvių
On 2012.12.29 15:35, Tomas Straupis wrote: Kiek prisimenu, formalūs reikalavimai tam yra tokie: - namų (adresų) ne daugiau 20 = apribojimas namo numeriui; - tame kaime nėra nė vienos gatvės 1. „ 20“ - nepakankama sąlyga. 2. „Kaime nėra gatvių“: a) beveik nė vienas kaimas neturi administracinių ribų (kol nesutarsime su registrų centru, nematau galimybių tokias ribas bent kiek realiu greičiu susivesti) b) galima būtų tikrinti, ar nuo kaimo taško kažkokiu spinduliu (tarkim 2km) yra bent viena gatvė su pavadinimu, bet toks variantas netiks, nes gali būti, kad gatvė su pavadinimu realiai yra, tik ji nepažymėta (tarkim tiesiog nėra „name“ žymos). Vienas iš dalykų, kas daroma tvarkant adresus - jei randami pastatai su tarkim gatve „Baibalių g.“, tai tikėtina, kad ir gatvė greta yra „Baibalių g.“. Na, jei adresas yra Džiuginėnų k. 7, tai kaip jis užsirašo? addr:city=Džiuginėnų k., addr:houseNumber=7? Mano pasiūlymas buvo pagrupuoti visus objektus pagal addr:city, surasti kiek skirtingų addr:street reikšmių kiekvienas city turi, ir klaidų „trūksta addr:street“ negeneruoti tiems addr:city, kur reikšmė yra 1 (tuščią/ trūkstamą laikant atskirtu variantu). -- Aidas Kasparas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Adresai be gatvių
2012 m. gruodis 29 d. 16:16, Aidas Kasparas rašė: Na, jei adresas yra Džiuginėnų k. 7, tai kaip jis užsirašo? addr:city=Džiuginėnų k., addr:houseNumber=7? Mano pasiūlymas buvo pagrupuoti visus objektus pagal addr:city, surasti kiek skirtingų addr:street reikšmių kiekvienas city turi, ir klaidų „trūksta addr:street“ negeneruoti tiems addr:city, kur reikšmė yra 1 (tuščią/ trūkstamą laikant atskirtu variantu). Neblogas variantas, bet neveiks, kol turime daug miestų/kaimų su labai silpnu adresų užpildymu... Taigi šitą variantą būtų galima „įvesti“ tada, kai turėsim daugmaž normalų adresų užpildymą (pagal šiandienines tendencijas - po 34 metų...). 2012 m. gruodis 29 d. 15:54, Darius Žitkevičius rašė: Aš galvoju apie navigacijas. Dauguma įvedinėjant adresus prašo nurodyti gatvę. Jei gatvės pavadinimo nebus, arba bus kažkoks simsalabim, tokiu atveju adreso paieška komplikuojasi. Jei būtu kamo pavadinimas, tai paieška ras vieną gatvę, kas atitinka realybę. Chrm. Reikia pabandyti. Štai yra „kandidatas“: http://www.openstreetmap.org/browse/way/148226088 addr:city ir addr:nostreet uždėjau šiandien, tai truputį reikia palaukti, kol persigeneruos žemėlapiai ir nominatimo db. Tada žiūrėsim, kaip veikia adreso paieška, kai visiškai nenurodyta gatvė. (garmin bus rytoj, nominatim skelbiasi, kad greitai pakeitimus susirenka, kokia kita programa, tarkim OsmAnd sunku pasakyti, kas kiek žemėlapį pergeneruoja...) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
[Talk-es] Desplazamiento Ortofotos BING vs PNOA
Hola, teneis que tener en cuenta que las fotos estas hechas desde el satelite, y que algunas veces la inclinacion de los edificios o las sombras pueden engañar al ojo con la perspectiva de las fotos. Yo siempre me baso en catastro, ya que como digo algunas calles pueden parecer desplazadas por la perspectiva o incluso tapadas por edificios. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Desplazamiento Ortofotos BING vs PNOA
Las ortofotos se hacen desde avión. 2012/12/29 Fco. Javier González Jiménez fjavier...@hotmail.com: Hola, teneis que tener en cuenta que las fotos estas hechas desde el satelite, y que algunas veces la inclinacion de los edificios o las sombras pueden engañar al ojo con la perspectiva de las fotos. Yo siempre me baso en catastro, ya que como digo algunas calles pueden parecer desplazadas por la perspectiva o incluso tapadas por edificios. Saludos. -- Atentamente, Suárez ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Desplazamiento Ortofotos BING vs PNOA
El día 29 de diciembre de 2012 14:30, Alejandro S. alejandro...@gmail.com escribió: Las ortofotos se hacen desde avión. ...y que algunas veces la inclinacion de los edificios o las sombras pueden engañar al ojo con la perspectiva de las fotos. Ese efecto depende de la distancia del edificio al centro de la foto, suponiendo el avion recto y nivelado en el momento del disparo. Del edificio que está en el centro de la foto se verá solo la azotea, De los edificios a la derecha se verá algo de la fachada izquierda y de los situados a la izquierda, la fachada derecha. Mas fachada cuanto más alejados del centro de la foto. Obviamente la escala tambien varía aunque se supone que en una ortofoto eso está ya corregido -- Roberto Plà http://robertopla.net/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ro] Oraș nou lângă București
Intradevar, nu mai exista acest oras in prezent. Dar trebuie sa spun, ca printre orasele daramate de Ceausescu pentru asi umple blocurile Bucurestiului se afla un sat numit Brozari. O biserica din acel sat se numea intr-adevar Biserica Sfantul Nicolae Brozari. De un muzeu astronomic nu stiu nimic. Eu stiu asta, deoarece bunicii mei au locuit in acel sat si au fost mutati in Militari. -- View this message in context: http://gis.19327.n5.nabble.com/Ora-nou-lang-Bucure-ti-tp5741821p5741924.html Sent from the Romania mailing list archive at Nabble.com. ___ Talk-ro mailing list Talk-ro@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ro
[Talk-lv] celju seguma dati
http://osm.lv/blog/2012/12/celu-seguma-dati/ taa kaa aaraa sniegs, varam peec atminjas likt surface datus ;) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-ca] Toronto OpenStreetMap Meet and Greet
We've confirmed the date and time, and the special guest, for the Toronto meet and greet. It will be next Saturday, 05 Jan 2013, from 3pm. http://www.meetup.com/OpenStreetMap-Toronto/ Join the meetup, or email me off list for details. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China)
Hi, In this post of Talk-US, Frederik suggests NOT mapping administrative boundaries that are not visible on ground (fences, toll, etc...) http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010026.html Don't you think that the notion of virtual or not is absolutly not applicable on administrative boundaries?! Since humanity exists, administrative boundaries determines the link beetween (population) Gouvernements and Geography. Look at our history: except The Great Wall of China, most of old and big Empires settled their boundaries without marks (fences). Look at most administrative boundaries in Sahel (Mali, Mauritanie) or in the the United States (Nevada, Arizona): Long strait virtual lines into Desert Land, without fences neither natural limits (rivers...). And what about limits beetween USA and Canada in the Oceans and See? Do we delete those boundaries because they're not visible? So ... deleting (or nor drawing) administrative boundaries makes no sence in this way! Dont'you mind? A Map has to be a citizen information of administrative and geographical data (and this includes administrative boundaries) and not 2D version of what OpenStreetMap offers in 3D version With political, historical and administrative point-of-view a map should not apply the principe of What You See Is What You Get. If this were the case, only satelites will remain the only single base material of GIS, and map will die! Isn't it? I don't think so but i wonder the absurdity of such arguments in favor of WYSIWYG in mapping. What do you think of that? Bruno Remy ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China)
Bruno, Frederik tiens un discours idéologique sans savoir à quoi servent de telles informations. Je pourrais toujours dire que je demeure sur la rue ensoleillée, dans un village nulle part. Difficile de s'y retrouver. Les limites administratives, tout comme les noms de rues sont un élément essentiel d'une base de donnée comme OSM. Essaie de rechercher, à partir de Nominatim, un nom de rue lorsque les limites administratives de la municipalité ne sont pas tracées. Tout cela me semble bien plus utile que de tracer des clôtures parce que ça fait beau. Pierre De : Bruno Remy bremy.qc...@gmail.com À : talk-ca@openstreetmap.org talk-ca@openstreetmap.org Envoyé le : Samedi 29 décembre 2012 12h49 Objet : [Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China) Hi, In this post of Talk-US, Frederik suggests NOT mapping administrative boundaries that are not visible on ground (fences, toll, etc...) http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010026.html Don't you think that the notion of virtual or not is absolutly not applicable on administrative boundaries?! Since humanity exists, administrative boundaries determines the link beetween (population) Gouvernements and Geography. Look at our history: except The Great Wall of China, most of old and big Empires settled their boundaries without marks (fences). Look at most administrative boundaries in Sahel (Mali, Mauritanie) or in the the United States (Nevada, Arizona): Long strait virtual lines into Desert Land, without fences neither natural limits (rivers...). And what about limits beetween USA and Canada in the Oceans and See? Do we delete those boundaries because they're not visible? So ... deleting (or nor drawing) administrative boundaries makes no sence in this way! Dont'you mind? A Map has to be a citizen information of administrative and geographical data (and this includes administrative boundaries) and not 2D version of what OpenStreetMap offers in 3D version With political, historical and administrative point-of-view a map should not apply the principe of What You See Is What You Get. If this were the case, only satelites will remain the only single base material of GIS, and map will die! Isn't it? I don't think so but i wonder the absurdity of such arguments in favor of WYSIWYG in mapping. What do you think of that? Bruno Remy ___ 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: [Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China)
I took from that message that the person was talking about not putting property lines in OSM, not about removing geopolitical boundaries. Mapping property lines is problematic for your average mapper and doing so accurately is an even bigger challenge. If I had to pick where to expend my mapping resources, I'd pick other things to map first before mapping lot lines. Oh, and the Romans built walls all over the place to define their boundaries, many of which are still in existence today (eg Hadrian's Wall). --G Sent from my iPhone. On 2012-12-29, at 12:49, Bruno Remy bremy.qc...@gmail.com wrote: Hi, In this post of Talk-US, Frederik suggests NOT mapping administrative boundaries that are not visible on ground (fences, toll, etc...) http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010026.html Don't you think that the notion of virtual or not is absolutly not applicable on administrative boundaries?! Since humanity exists, administrative boundaries determines the link beetween (population) Gouvernements and Geography. Look at our history: except The Great Wall of China, most of old and big Empires settled their boundaries without marks (fences). Look at most administrative boundaries in Sahel (Mali, Mauritanie) or in the the United States (Nevada, Arizona): Long strait virtual lines into Desert Land, without fences neither natural limits (rivers...). And what about limits beetween USA and Canada in the Oceans and See? Do we delete those boundaries because they're not visible? So ... deleting (or nor drawing) administrative boundaries makes no sence in this way! Dont'you mind? A Map has to be a citizen information of administrative and geographical data (and this includes administrative boundaries) and not 2D version of what OpenStreetMap offers in 3D version With political, historical and administrative point-of-view a map should not apply the principe of What You See Is What You Get. If this were the case, only satelites will remain the only single base material of GIS, and map will die! Isn't it? I don't think so but i wonder the absurdity of such arguments in favor of WYSIWYG in mapping. What do you think of that? Bruno Remy ___ 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: [Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China)
j'ai d'abord répondu à partir du compte-rendu de Bruno. En retournant à la discussion originale, je m'aperçois que c'est Frederik Ramm qui a écrit la note en question. Frederik est sur le conseil d'administration de la Fondation OSM et sur le comité de surveillance des données (DWG). Dans cette note, Frederik ne parle effectivement pas de limites administratives, mais plutôt d'imports en général. Frederik aime bien envoyer de temps en temps de tels pavés dans la mare. Mais cette fois-ci, il ne semble pas avoir prévu le rebond du cailloux! Les membres du DWG sont responsables d'assurer l'intégrité de la base OSM. Mais malheureusement, certains d'entre eux tiennent parfois un discours idéologique disant que ce n'est pas bien d'importer des données venant des gouvernements. Il y a eu une longue polémique sur la liste Talk récemment relative à l'imposition par le DWG de l'utilisation d'un deuxième compte usager pour l'import de données, sans vraiment pouvoir le justifier ni obtenir un consensus là-dessus. Espérons que les relations entre les membres du DWG et les membres OSM en général pourront cheminer dans des directions plus constructives pour notre organisation. La question à se poser, c'est dans quel but on développe les données OSM. Ce n'est sûrement pas pour simplement s'amuser à tracer les chemins que l'on a parcouru. La carte doit être complète, utile pour diverses analyses, pour l'import dans des GPS, permettre de développer divers API dont sur les téléphones multifonction. Au Canada par exemple, est-il réaliste de penser que l'on ne doit pas faire d'import des données de Canvec? Pierre De : Gordon Dewis gor...@pinetree.org À : Bruno Remy bremy.qc...@gmail.com Cc : talk-ca@openstreetmap.org talk-ca@openstreetmap.org Envoyé le : Samedi 29 décembre 2012 13h06 Objet : Re: [Talk-ca] Deleting non-visible Administrative Boundaries (or The Great Wall of China) I took from that message that the person was talking about not putting property lines in OSM, not about removing geopolitical boundaries. Mapping property lines is problematic for your average mapper and doing so accurately is an even bigger challenge. If I had to pick where to expend my mapping resources, I'd pick other things to map first before mapping lot lines. Oh, and the Romans built walls all over the place to define their boundaries, many of which are still in existence today (eg Hadrian's Wall). --G Sent from my iPhone. On 2012-12-29, at 12:49, Bruno Remy bremy.qc...@gmail.com wrote: Hi, In this post of Talk-US, Frederik suggests NOT mapping administrative boundaries that are not visible on ground (fences, toll, etc...) http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010026.html Don't you think that the notion of virtual or not is absolutly not applicable on administrative boundaries?! Since humanity exists, administrative boundaries determines the link beetween (population) Gouvernements and Geography. Look at our history: except The Great Wall of China, most of old and big Empires settled their boundaries without marks (fences). Look at most administrative boundaries in Sahel (Mali, Mauritanie) or in the the United States (Nevada, Arizona): Long strait virtual lines into Desert Land, without fences neither natural limits (rivers...). And what about limits beetween USA and Canada in the Oceans and See? Do we delete those boundaries because they're not visible? So ... deleting (or nor drawing) administrative boundaries makes no sence in this way! Dont'you mind? A Map has to be a citizen information of administrative and geographical data (and this includes administrative boundaries) and not 2D version of what OpenStreetMap offers in 3D version With political, historical and administrative point-of-view a map should not apply the principe of What You See Is What You Get. If this were the case, only satelites will remain the only single base material of GIS, and map will die! Isn't it? I don't think so but i wonder the absurdity of such arguments in favor of WYSIWYG in mapping. What do you think of that? Bruno Remy ___ 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 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Značení chatových oblastí
Pokud se dívám na mapu tak landuse=allotments je praxe pro všechny chaty nebo zahrádkářské kolonie. Pokud je potřeba to rozlišovat, tak ať je to nějaký doplňḱový tag. Navíc jsem skeptický vůči tomu, že v OSM bude reálně možné postihovat všechna národní/kulturní specifika. hanoj Dne 22. prosince 2012 20:12 Marcel Dopita m...@rcel.cz napsal(a): Dobrý den, už delší dobu přemýšlím a stále nenacházím žádné informace o tom, jak (a jestli) značit tag landuse u různých chatových oblastí. Zahrádkářské kolonie tag mají, ale chatové oblasti jsou přeci jen specialita ČR. Měla by se tedy správně nějak značit oblast, která je v územním plánu značena jako rekreační zástavba (jsou na ní postaveny klasické pevné domy, plotem oddělené zahrady a je několik čísel popisných)? ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] 75 pourcent
cela concerne la correction des erreurs liés a l'import semi-automatique des données du cadastre: pour toute la zone couverte par osmose (y compris les pays étrangers) debut avril, il y avait 220 000 chevauchements debut septembre, il en estait 110 000 aujourd'hui il n'en reste que 54212 pour la zone cadastre, depuis début avril: nombre de corrections de chevauchements corrigés: plus de 630 mille soit 2300 par jour nombre de chevauchements en plus (nouveaux imports): au moins 240 mille soir 880 par jour * il reste 39 000 mille corrections a faire dont 4700 a faire manuellement merci aux personnes qui corrigent et/ou qui effectuent des imports propres et a osmose bien sur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 75 pourcent
j'ai oublié le pdf pour les courbes ... Le samedi 29 décembre 2012 à 08:57 +0100, didier2020 a écrit : cela concerne la correction des erreurs liés a l'import semi-automatique des données du cadastre: pour toute la zone couverte par osmose (y compris les pays étrangers) debut avril, il y avait 220 000 chevauchements debut septembre, il en estait 110 000 aujourd'hui il n'en reste que 54212 pour la zone cadastre, depuis début avril: nombre de corrections de chevauchements corrigés: plus de 630 mille soit 2300 par jour nombre de chevauchements en plus (nouveaux imports): au moins 240 mille soir 880 par jour * il reste 39 000 mille corrections a faire dont 4700 a faire manuellement merci aux personnes qui corrigent et/ou qui effectuent des imports propres et a osmose bien sur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr bcTotal.pdf Description: Adobe PDF document ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Application natural=water vers piscines en un clic?
Le samedi 29 décembre 2012 à 08:27 +0100, JB a écrit : Pour avoir corrigé pas mal de piscines, la technique du bot ne fonctionne pas (beaucoup d'étangs ou de petits bassins). Par contre, le copier-coller de tags est efficace : Controle+Majuscule+V par défaut, mais modifiable en « 1 » touche dans les préférences… j'ai ajouté le bouton piscine dans la barre de menu de josm didier JB Le 28.12.2012 23:30, PierreV a écrit : Bonsoir, eff Je ne pense pas que ce soit déja un outil existant... mais je pense que l'on pourrait simplifier le nombre de clics pour les contributeurs voulant changer les quelques 28 000 erreurs de natural=water vers piscines que osmose repère... Car pour l'instant il faut cliquer un par un les erreurs, ajouter les bon tags, et supprimer les mauvais... Bref pas mal de clics de souris. Serait-il possible qu'un de nos merveilleux programmateur puisse nous sortir un petit outil de validation de ses erreurs en un clic? Genre avec une visualisation sur un fond Bing... Voila, juste une idée de fin d'année... ;-) et qui nous permettrai de faire un pas en avant pour éventuellement revoir la couche water sur l'import du cadastre? -- View this message in context: http://gis.19327.n5.nabble.com/Application-natural-water-vers-piscines-en-un-clic-tp5741865.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ 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] problème osmosis ou mkgmap ?
Salut ! Je pense que ton probleme est lié à la v0.39 d'Osmosis. J'avais
ce meme genre d'erreur avant de migrer vers 0.41. La nouvelle version
permet de gerer les fichiers sources au delà du seuil des 2 Go
principalement (quand on traite France entière) mais corrige également
pas mal de soucis divers, tu devrais essayer.
Tant que t'y es, ton Mkgmap meriterait aussi un p'tit update, on en est
à 2427 quand meme ! :) Je crois que tu n'as pas à adapter tes fichiers
de configs seront conservés, c'est compatible.
http://www.mkgmap.org.uk/download/mkgmap.html
Sinon, si tu regardes ton fichier source ${fichier}.osm il a un bon
look de XML correct ? Il faudrait que tu ailles voir la ligne 2549432
caractère 91 pour vérifier qu'il ne s'est pas glissé un caractère
bizarre dans le fichier...
Le 27/12/12 23:37, philippe a écrit :
bonjour,
ça fait un moment que j'ai pas eu à générer de cartes pour mon gps
mais là j'ai besoin de me faire une petite carte de la région de
fontromeu pour mes vacances la semaine prochaine et horreur mon script
ne marche plus :-(
Je récupère la carte de midi-pyrénées sur geofabrick que je
décompresse, puis je lance d'abord osmosis avec une ligne de commande
genre :
osmosis.bat --read-xml ${fichier}.osm ${bbox} --write-xml ${dest}.osm
et visiblement ça se passe pas bien
8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--
# lancement de osmosis :
27 déc. 2012 23:21:32 org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.39
27 déc. 2012 23:21:33 org.java.plugin.registry.xml.ManifestParser init
INFO: got SAX parser factory -
org.apache.xerces.jaxp.SAXParserFactoryImpl@1d6776d
27 déc. 2012 23:21:33 org.java.plugin.registry.xml.PluginRegistryImpl
configure
INFO: configured, stopOnError=false, isValidating=true
27 déc. 2012 23:21:33 org.java.plugin.registry.xml.PluginRegistryImpl
register
INFO: plug-in and fragment descriptors registered - 1
27 déc. 2012 23:21:33 org.java.plugin.standard.StandardPluginManager
activatePlugin
INFO: plug-in started - org.openstreetmap.osmosis.core.plugin.Core@0.39.0
27 déc. 2012 23:21:33 org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
27 déc. 2012 23:21:33 org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
27 déc. 2012 23:21:33 org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
27 déc. 2012 23:21:41
org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager
waitForCompletion
GRAVE: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to
parse xml file midi-pyrenees.osm. publicId=(null), systemId=(null),
lineNumber=2549432, columnNumber=91.
at
org.openstreetmap.osmosis.xml.v0_6.XmlReader.run(XmlReader.java:113)
at java.lang.Thread.run(Unknown Source)
Caused by: org.xml.sax.SAXParseException: XML document structures must
start and end within the same entity.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at
org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.endEntity(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at
org.openstreetmap.osmosis.xml.v0_6.XmlReader.run(XmlReader.java:108)
... 1 more
27 déc. 2012 23:21:41 org.openstreetmap.osmosis.core.Osmosis main
GRAVE: Execution aborted.
[OSM-talk-fr] zones inondables
il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? jeff ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
Le 29 déc. 2012 à 09:53, Jean-François Gaffard a écrit : il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? Ce serait pas mal, certain PPRI sont disponibles en shp sur le site data.gouv.fr, la couverture du territoire n'est que très partielle, les PPRI sont souvent encore en cours d'élaboration par les DREAL (à moins que ce ne soit les DDE ou le ministère de l'écologie…). restent plusieurs questions : - intérêt de cartographier ces zones dans OSM, c'est la même question que pour les périmètres de Monuments historiques les Sites classés et inscrit (ministère d ela Culture) ou autres servitudes régaliennes ? - quel rendu ? à quelle échelle ? - comment définir une zone inondable ? à partir de quel débit ? à partir de quelle fréquence d'inondabilité ? Les PPRI définissent plusieurs zones les quelles retenir ? plus de questions que de réponses… jeff ___ 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] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le vendredi 21 décembre 2012 à 15:33 +0100, sly (sylvain letuffe) a écrit : On vendredi 21 décembre 2012, ades_...@orange.fr wrote: que faut-il en conclure ? Il faut croire ce que nous savons déjà et que beaucoup dans notre communauté se refusent à accepter ce qui met en insécurité juridique tout ré-utilisateur de données françaises, qui n'aurait pas suivi cette histoire avec assiduité et pris les dispositions qui consiste à convertir des données OSM en france en vrai ODBL (=retrait de relation et des mentions GR/PR) GR/PR = pas dans OSM Je rajoute une pièce au juke box... http://www.sudouest.fr/2012/12/28/-920401-4583.php Cet article parle du projet de transformer le chemin Henri IV qui relie Pau à Lourdes en GR. http://www.rando64.fr/8-12834-Le-Chemin-Henri-IV.php Cela signifie t'il que du jour au lendemain, ce chemin deviendra une propriété intellectuelle et oeuvre de l'esprit de la FFRP et qu'OpenStreetMap devra l'effacer de sa base de données ? En tout cas, comme je l'ai déjà dit, hors de question en ce qui me concerne de cautionner ce genre d'interprétation, le Chemin Henri IV restera dans la base, même s'il devient un GR ! Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
Le 29/12/2012 10:20, ades_...@orange.fr a écrit : Le 29 déc. 2012 à 09:53, Jean-François Gaffard a écrit : il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? Ce serait pas mal, certain PPRI sont disponibles en shp sur le site data.gouv.fr, la couverture du territoire n'est que très partielle, les PPRI sont souvent encore en cours d'élaboration par les DREAL (à moins que ce ne soit les DDE ou le ministère de l'écologie…). restent plusieurs questions : - intérêt de cartographier ces zones dans OSM, c'est la même question que pour les périmètres de Monuments historiques les Sites classés et inscrit (ministère d ela Culture) ou autres servitudes régaliennes ? - quel rendu ? à quelle échelle ? - comment définir une zone inondable ? à partir de quel débit ? à partir de quelle fréquence d'inondabilité ? Les PPRI définissent plusieurs zones les quelles retenir ? plus de questions que de réponses… Bonjour, Il pourrait aussi vous intéresser de consulter les pages suivantes : - plus généralement, sur les risques naturels, incluant les risques d'inondation comme un cas particulier : https://wiki.openstreetmap.org/wiki/OpenHazardMap (qui me semble présenter un bon compromis entre la complétude et la précision des informations et la possibilité d'utilisation dans OSM --- pas forcément par des spécialistes), - (ainsi qu'éventuellement la page --- plus ancienne --- spécifiquement sur les zones inondables : https://wiki.openstreetmap.org/wiki/Key:flood_prone ). Cordialement, Jean-Guilhem ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
reste tjs la question : Should the hazard data be stored along with the traditional OSM data? If not, what should be the most appropriate structure to ensure compatibility and ease of use? (en bas de https://wiki.openstreetmap.org/wiki/OpenHazardMap;) et si ce doit être intégré dans OSM, faut-il tagger toutes les entités de la zone de risque ? Se pose également la question de savoir si le marquage des zones de risque naturel ne doit se faire qu'à partir des données officielles ou si les mappeurs peuvent indiquer celles qu'ils connaitraient. Pour le territoire français je pencherais plutôt vers les données officielles (au fur et à mesure de leur établissement et à condition que ces données ne soient pas modifiable, un peu comme les poinstsgéodésiques) plutôt que pour le travail des mapeurs, sauf à tagger ces zones comme zone pouvant peut-être être ultérieurement définie comme zone à risque . Le risque principal de la production de mappeurs est celui de l'instrumentalisation de la donnée, signalé aussi en bas de la même page : What is the risk of vandalism and how to fight against it? As real estate prices highly depend on the safety of the location (who would like to buy a flat in what is known as landslide-prone area?), wouldn't some people be tempted to create nonexistent hazard zones or to suppress actual zones?. structure to ensure compatibility and ease of use? Le 29 déc. 2012 à 11:13, Jean-Guilhem Cailton a écrit : Le 29/12/2012 10:20, ades_...@orange.fr a écrit : Le 29 déc. 2012 à 09:53, Jean-François Gaffard a écrit : il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? Ce serait pas mal, certain PPRI sont disponibles en shp sur le site data.gouv.fr, la couverture du territoire n'est que très partielle, les PPRI sont souvent encore en cours d'élaboration par les DREAL (à moins que ce ne soit les DDE ou le ministère de l'écologie…). restent plusieurs questions : - intérêt de cartographier ces zones dans OSM, c'est la même question que pour les périmètres de Monuments historiques les Sites classés et inscrit (ministère d ela Culture) ou autres servitudes régaliennes ? - quel rendu ? à quelle échelle ? - comment définir une zone inondable ? à partir de quel débit ? à partir de quelle fréquence d'inondabilité ? Les PPRI définissent plusieurs zones les quelles retenir ? plus de questions que de réponses… Bonjour, Il pourrait aussi vous intéresser de consulter les pages suivantes : - plus généralement, sur les risques naturels, incluant les risques d'inondation comme un cas particulier : https://wiki.openstreetmap.org/wiki/OpenHazardMap (qui me semble présenter un bon compromis entre la complétude et la précision des informations et la possibilité d'utilisation dans OSM --- pas forcément par des spécialistes), - (ainsi qu'éventuellement la page --- plus ancienne --- spécifiquement sur les zones inondables : https://wiki.openstreetmap.org/wiki/Key:flood_prone ). Cordialement, Jean-Guilhem ___ 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] relations boundary modifiées par Philippe Verdy – Tirets
Merci pour les divagations... mais tu as divagué tout seul en inventant des raisons qui n'étaient pas les miennes. Je TE cite: J'en déduis que ses tirets cadratins ne servent uniquement à satisfaire l'égo de celui qui les a découvert depuis peu et est fier d'avoir trouvé comment les écrire sur son clavier. Pure invention de ta part Le 29 décembre 2012 04:01, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Le 29/12/2012 à 05:38:47 +1100 Philippe Verdy verd...@wanadoo.fr a écrit Objet: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets : Le 28 décembre 2012 19:07, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : J'en déduis que ses tirets cadratins ne servent uniquement à satisfaire l'égo de celui qui les a découvert depuis peu et est fier d'avoir trouvé comment les écrire sur son clavier. Mais qu'est-ce qu'il ne faut pas INVENTER quand on n'a aucun argument : Qu'est-ce que tu en sais que je les aurais depuis peu sur mon clavier ? RIEN DU TOUT parce que tu te trompes complètement. Et je me trompes aussi si je ne vois pas de similitude entre France — Belgique et Nouvelle-Calédonie — eaux territoriales ? Expliques-moi bien en quoi ces deux cas sont pareils et nécessitent le même tiret cadratin. Ce n'est pas une question d'égo sinon poses-toi la question même de l'existence de ces caractères dans des codages anciens bien avant même leur encodage dans Unicode, et leur présence sur tous les jeux 8-bits Windows, MacOS, PostScript. Depuis près de moins 30 ans déjà (sinon bien plus encore avant l'informatique, c'est une tradition très ancienne). Où est donc mon égo, comme si j'avais prétendu les avoir inventés ? Ce n'est pas parce que tu n'en comprends pas l'utilité ou qu'on ne t'a pas appris ou que tu ne veux pas apprendre, que tu vas insulter les nombreux qui les ont utilisés et définis depuis des siècles. Pour qui tu te prends pour te croire supérieur à toutes ces générations, pas passées du tout ? Je n'ai pas insultés les nombreux qui les utilisent depuis des siècles. Mais tu auras raison à l'issu d'écrits verbeux et divagants. Donc pour moi le sujet de qui insulte qui est clos ici. -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ 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] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org a écrit : Cela signifie t'il que du jour au lendemain, ce chemin deviendra une propriété intellectuelle et oeuvre de l'esprit de la FFRP et qu'OpenStreetMap devra l'effacer de sa base de données ? En tout cas, comme je l'ai déjà dit, hors de question en ce qui me concerne de cautionner ce genre d'interprétation, le Chemin Henri IV restera dans la base, même s'il devient un GR ! Tout à fait d'accord. Ce genre d'appropriation exclusive des droits communs des autres est un abus qui ne doit pas être toléré. Même si la mention GR ne figure pas dans la base (si on admet alors que c'est juste un label propriétaire, que seule la FFRP peut décerner, il restera que ces chemins ne lui appartiennent pas, et qu'ils auront été construits/balisés et relevés sur le terrain par d'autres). Sinon demain je déclare que les autoroutes françaises m'appartiennent parce que je vais décider de les appeler toutes autostrades avec ma propre numérotation. En quoi cela devrait changer le droit de mentionner les autoroutes existantes ? Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
Le 29 décembre 2012 12:01, ades_...@orange.fr ades_...@orange.fr a écrit : reste tjs la question : Should the hazard data be stored along with the traditional OSM data? If not, what should be the most appropriate structure to ensure compatibility and ease of use? (en bas de https://wiki.openstreetmap.org/wiki/OpenHazardMap;) et si ce doit être intégré dans OSM, faut-il tagger toutes les entités de la zone de risque ? Se pose également la question de savoir si le marquage des zones de risque naturel ne doit se faire qu'à partir des données officielles ou si les mappeurs peuvent indiquer celles qu'ils connaitraient. Pour le territoire français je pencherais plutôt vers les données officielles (au fur et à mesure de leur établissement et à condition que ces données ne soient pas modifiable, un peu comme les poinstsgéodésiques) plutôt que pour le travail des mapeurs, sauf à tagger ces zones comme zone pouvant peut-être être ultérieurement définie comme zone à risque . Le risque principal de la production de mappeurs est celui de l'instrumentalisation de la donnée, signalé aussi en bas de la même page : What is the risk of vandalism and how to fight against it? As real estate prices highly depend on the safety of the location (who would like to buy a flat in what is known as landslide-prone area?), wouldn't some people be tempted to create nonexistent hazard zones or to suppress actual zones?. Ce sont des questions générales au projet OSM et pas uniquement aux données de zones inondables ou à risque: fiabilité de l'info, vandalisme, mauvais usage des data. La réponse à ces questions a-t-elle besoin d'être différente pour ce cas précis ? Lorsque l'on intègre des données officielles, on peut l'indiquer avec le tag source. Si ces données sont vraiment trop sensibles, autant les laisser en dehors d'OSM. N'est-il pas possible de plutôt créer des liens vers une source officielle d'info ? -- 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] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Bonjour Le 29/12/2012 12:34, Philippe Verdy a écrit : Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. Peux-tu rappeler, pour ceux qui ne le savent pas ou plus, la nomenclature générique internationale ? Merci -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
cela répond en partie à mes interrogations quelques cas concrets au Tchad : http://www.openstreetmap.org/?lat=8.4403lon=16.8642zoom=14layers=M j'ai cartographié ce que je voyais sur Bing (rivière en étiage) http://www.openstreetmap.org/?lat=7.9138lon=16.6066zoom=14layers=M un autre contributeur n'a retenu que quelques îles (rivière moyenne ?) mais on voit bien que la vallée inondable est bien plus large ici sur une autre rivière c'est la crue qui est cartographiée http://www.openstreetmap.org/?lat=7.9138lon=16.6066zoom=14layers=M périmètre qui doit être dépassé comme en septembre de cette année en cas de crues exceptionnelles. voila pourquoi il me semblerait utile d'avoir un tag particulier sur ces vallées inondables (on voit bien qu'il n'y a pas de cultures, qu'il y a des traces d'inondations récurrentes mais il me semble difficile de tagger par waterway = riverbank) y aurait-il un consensus d'usage ? Le samedi 29 décembre 2012 à 11:13 +0100, Jean-Guilhem Cailton a écrit : Le 29/12/2012 10:20, ades_...@orange.fr a écrit : Le 29 déc. 2012 à 09:53, Jean-François Gaffard a écrit : il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? Ce serait pas mal, certain PPRI sont disponibles en shp sur le site data.gouv.fr, la couverture du territoire n'est que très partielle, les PPRI sont souvent encore en cours d'élaboration par les DREAL (à moins que ce ne soit les DDE ou le ministère de l'écologie…). restent plusieurs questions : - intérêt de cartographier ces zones dans OSM, c'est la même question que pour les périmètres de Monuments historiques les Sites classés et inscrit (ministère d ela Culture) ou autres servitudes régaliennes ? - quel rendu ? à quelle échelle ? - comment définir une zone inondable ? à partir de quel débit ? à partir de quelle fréquence d'inondabilité ? Les PPRI définissent plusieurs zones les quelles retenir ? plus de questions que de réponses… Bonjour, Il pourrait aussi vous intéresser de consulter les pages suivantes : - plus généralement, sur les risques naturels, incluant les risques d'inondation comme un cas particulier : https://wiki.openstreetmap.org/wiki/OpenHazardMap (qui me semble présenter un bon compromis entre la complétude et la précision des informations et la possibilité d'utilisation dans OSM --- pas forcément par des spécialistes), - (ainsi qu'éventuellement la page --- plus ancienne --- spécifiquement sur les zones inondables : https://wiki.openstreetmap.org/wiki/Key:flood_prone ). Cordialement, Jean-Guilhem ___ 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] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Je n'ai pas dit la mais une. Nuance... Le 29 décembre 2012 13:55, David Crochet david.croc...@online.fr a écrit : Bonjour Le 29/12/2012 12:34, Philippe Verdy a écrit : Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. Peux-tu rappeler, pour ceux qui ne le savent pas ou plus, la nomenclature générique internationale ? Merci -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Bonjour à tous
C'était mineure, en chargeant le cadastre de mon village il y avait des décalage d'un mètre ou deux par rapport aux limites indiquées dans OSM. Parfois il manquait de précision dans les contours et j'ai donc affiner l'ensemble pour que cela corresponde mieux à ce que je connaît sur plus. J'ai donc ajusté au plus près les limites résidentielle et les frontières avec les autres communes selon le cadastre et quelques relevé gps effectué sur place. Je pense avoir fait cela au mieux, maintenant que j'ai fait le tour de la commune, un contrôle extérieur serait le bienvenu. Il me reste encore 2 quartier à parcourir à pied pour mettre à jour la carte et ça devrait être bon. Le 28 décembre 2012 22:30, Pieren pier...@gmail.com a écrit : 2012/12/28 Jo. perche...@gmail.com: Bonjour à tous, Bienvenue sur OSM J'ai déjà fait pas mal de modifications (ajustement des limites administrative, ajustement des limites administratives ? pourrais-tu en dire plus ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org a écrit : Cela signifie t'il que du jour au lendemain, ce chemin deviendra une propriété intellectuelle et oeuvre de l'esprit de la FFRP et qu'OpenStreetMap devra l'effacer de sa base de données ? En tout cas, comme je l'ai déjà dit, hors de question en ce qui me concerne de cautionner ce genre d'interprétation, le Chemin Henri IV restera dans la base, même s'il devient un GR ! Bien que je sois plutôt partisan de la prudence en ce qui concerne les GR, dans ce cas précis, je ne vois pas ce que la FFRP viendrait réclamer. Le tracé existe depuis longtemps, ils ne pourront pas se prévaloir d'avoir créé l'itinéraire. Dans le même genre, on peut penser au GR 70, reprenant plus ou moins le chemin de R.L. Stevenson à travers les Cévennes. La FFRP n'a fait qu'apposer son label sur une idée existante. J'imagine difficilement un juge reconnaître la paternité de la FFRP sur cet itinéraire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29/12/2012 15:08, Matthias Dietrich a écrit : Le 29 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org mailto:red...@redfoxcenter.org a écrit : Cela signifie t'il que du jour au lendemain, ce chemin deviendra une propriété intellectuelle et oeuvre de l'esprit de la FFRP et qu'OpenStreetMap devra l'effacer de sa base de données ? En tout cas, comme je l'ai déjà dit, hors de question en ce qui me concerne de cautionner ce genre d'interprétation, le Chemin Henri IV restera dans la base, même s'il devient un GR ! Bien que je sois plutôt partisan de la prudence en ce qui concerne les GR, dans ce cas précis, je ne vois pas ce que la FFRP viendrait réclamer. Le tracé existe depuis longtemps, ils ne pourront pas se prévaloir d'avoir créé l'itinéraire. Dans le même genre, on peut penser au GR 70, reprenant plus ou moins le chemin de R.L. Stevenson à travers les Cévennes. La FFRP n'a fait qu'apposer son label sur une idée existante. J'imagine difficilement un juge reconnaître la paternité de la FFRP sur cet itinéraire. La réponse est la même que pour le Chemin de Saint Jacques. http://lists.openstreetmap.org/pipermail/talk-fr/2012-June/044463.html Donc on ne cartographie pas le GR70 mais bien le chemin de Stevenson, avec toute l'ambiguïté qu'il y a derrière. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones inondables
Jean-François, Dans le Delta intérieur du Niger au nord du Mali, de vastes zones parfois sur plusieurs kilomètres sont inondées à chaque année, incluant des terres agricoles. Les champs saturés d'eau sur l'imagerie Bing HR permettent de repérer ces zones inondables. Pour identifier ces zones, j'ai utilisé l'attribut flood_prone=yes, et pour les fermes, l'attribut landuse=farmland. voir http://www.openstreetmap.org/?lat=16.52lon=-0.136zoom=11layers=M Avec l'url du premier exemple que tu donnes, on voit bien que la zone inondable est plus grande avec de grandes stries dans les zones bordant la rivière. On ne saurait cependant pas dire à partir de l'imagerie Bing si les champs sont aussi inondés. Avec l'url des deuxième et troisième exemples, on voit des terres agricoles qui sont inondées à la saison des pluies. Face à Goré, dans la grande courbe de la rivière, je vois du côté ouest une grand pointe de terre avec loin du rivage une bande de sable indiquant semble-t-il le rivage à la saison des pluies. À mon avis, on devrait identifier cette zone comme inondable. L'avantage lorsque l'on est sur le terrain, c'est de pouvoir valider les observations faites à partir des images. Cela facilite ensuite leur interprétation. Pierre De : Jean-François Gaffard jean-francois.gaff...@laposte.net À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Samedi 29 décembre 2012 7h58 Objet : Re: [OSM-talk-fr] zones inondables cela répond en partie à mes interrogations quelques cas concrets au Tchad : http://www.openstreetmap.org/?lat=8.4403lon=16.8642zoom=14layers=M j'ai cartographié ce que je voyais sur Bing (rivière en étiage) http://www.openstreetmap.org/?lat=7.9138lon=16.6066zoom=14layers=M un autre contributeur n'a retenu que quelques îles (rivière moyenne ?) mais on voit bien que la vallée inondable est bien plus large ici sur une autre rivière c'est la crue qui est cartographiée http://www.openstreetmap.org/?lat=7.9138lon=16.6066zoom=14layers=M périmètre qui doit être dépassé comme en septembre de cette année en cas de crues exceptionnelles. voila pourquoi il me semblerait utile d'avoir un tag particulier sur ces vallées inondables (on voit bien qu'il n'y a pas de cultures, qu'il y a des traces d'inondations récurrentes mais il me semble difficile de tagger par waterway = riverbank) y aurait-il un consensus d'usage ? Le samedi 29 décembre 2012 à 11:13 +0100, Jean-Guilhem Cailton a écrit : Le 29/12/2012 10:20, ades_...@orange.fr a écrit : Le 29 déc. 2012 à 09:53, Jean-François Gaffard a écrit : il me semblerait utile de reprendre ce projet de tag http://wiki.openstreetmap.org/wiki/Proposed_features/floodplain Par exemple : en France, on doit pouvoir accéder à la cartographie réglementaire et dans le projet Tchad cela permettrait de cartographier un peu mieux ces rivières du sud à débit très variable entre saison sèche et saison des pluies. L'extension maximale pas forcement atteinte chaque année est assez visible sur les vues satellites. qu'en pensez-vous ? Ce serait pas mal, certain PPRI sont disponibles en shp sur le site data.gouv.fr, la couverture du territoire n'est que très partielle, les PPRI sont souvent encore en cours d'élaboration par les DREAL (à moins que ce ne soit les DDE ou le ministère de l'écologie…). restent plusieurs questions : - intérêt de cartographier ces zones dans OSM, c'est la même question que pour les périmètres de Monuments historiques les Sites classés et inscrit (ministère d ela Culture) ou autres servitudes régaliennes ? - quel rendu ? à quelle échelle ? - comment définir une zone inondable ? à partir de quel débit ? à partir de quelle fréquence d'inondabilité ? Les PPRI définissent plusieurs zones les quelles retenir ? plus de questions que de réponses… Bonjour, Il pourrait aussi vous intéresser de consulter les pages suivantes : - plus généralement, sur les risques naturels, incluant les risques d'inondation comme un cas particulier : https://wiki.openstreetmap.org/wiki/OpenHazardMap (qui me semble présenter un bon compromis entre la complétude et la précision des informations et la possibilité d'utilisation dans OSM --- pas forcément par des spécialistes), - (ainsi qu'éventuellement la page --- plus ancienne --- spécifiquement sur les zones inondables : https://wiki.openstreetmap.org/wiki/Key:flood_prone ). Cordialement, Jean-Guilhem ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29 décembre 2012 12:34, Philippe Verdy verd...@wanadoo.fr a écrit : Tout à fait d'accord. Ce genre d'appropriation exclusive des droits communs des autres est un abus qui ne doit pas être toléré. Même si la mention GR ne figure pas dans la base (si on admet alors que c'est juste un label propriétaire, que seule la FFRP peut décerner, il restera que ces chemins ne lui appartiennent pas, et qu'ils auront été construits/balisés et relevés sur le terrain par d'autres). Sinon demain je déclare que les autoroutes françaises m'appartiennent parce que je vais décider de les appeler toutes autostrades avec ma propre numérotation. En quoi cela devrait changer le droit de mentionner les autoroutes existantes ? Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. Ton analogie n'est pas correcte : ce n'est pas un problème de nomenclature. Tu peux renommer les GR si tu veux, tu éviteras simplement l'emploi de la marque déposée GR. Le cœur du problème, c'est l'itinéraire en lui-même (le fait de suivre une liste précise de chemins ou de tronçons de chemins). L'itinéraire en lui-même peut être revendiqué comme œuvre de l'esprit. Après est-ce que chaque GR est une œuvre de l'esprit de la FFRP ? Seul la justice pourrait répondre. C'est bien là qu'est l'incertitude concernant cette histoire de GR. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Hello, Je rebondis tardivement sur : http://lists.openstreetmap.org/pipermail/talk-fr/2012-November/051162.html Bien que l'avis fût unanime, et que mes chances de convaincre soient faibles, je vais quand même argumenter mon désaccord. Plutôt que de radoter (une fois de plus) je déterre des archives de Mars 2009 où j'exposais déjà mon avis préférentiel pour la tag ref plutôt que ref:INSEE ici : http://lists.openstreetmap.org/pipermail/talk-fr/2009-March/007604.html Mon avis, que j'ai jusqu'a présent maintenu, de préférer le tag ref dès que c'est possible concernait déjà les communes, mais s'affirme tout autant pour les départements. Je vais essayer de faire court : Ma préférence est d'opter pour un format : ref=73 + source:ref=INSEE au lieu de ref:INSEE=73 La raison en est l'uniformité mondial donc l'utilisation compatible dans les outils. De même qu'on ne choisi pas * name:en_français=tata mais name=tata * highway:français=autoroute mais highway=motorway Je pense que l'on devrait aussi utiliser ref=X et pas ref:Y=X Il y a 4 ans, je n'avais aucun exemple concret pour montrer le défaut de notre approche, maintenant j'ai nominatim. Nominatim cherche sur le tag ref et ne cherche pas sur ref:INSEE, démo : Un français moyen connait son département par son numéro, ça lui permet La demande suivante : http://nominatim.openstreetmap.org/search.php?q=73,france qui trouve, comme attendu par certains, la savoie en revanche : http://nominatim.openstreetmap.org/search.php?q=974,france ne trouve pas la réunion * pas plus que : http://nominatim.openstreetmap.org/search.php?q=73065,france ne trouve chambéry (dont le code INSEE est 73065) * Les mauvaises langues diront que c'est à cause des relations bizarres et tout ça mais que sinon ça aurait marché, mais en fait non, je n'ai pas exploré intégralement le code de nominatim, mais les ref:INSEE ne sont très certainement pas prises en compte et c'est pour ça que la réunion, qui n'a pas ref=974 ne sort pas de la recherche, alors que la savoie, qui a ref=73 elle sort. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
ps: C'est aussi pour ça que : http://suivi.openstreetmap.fr/communes/communes.csv.txt ne marche plus pour les DOM/TOM On pourrait argumenter que je n'ai qu'a réparer mon code pour prendre en compte ref:INSEE mais cela impliquerait que mon code serait encore moins portable pour un autre pays qui aurait le même besoin. Je renâcle donc à le faire, oui, mais pour une raison réfléchie. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Je ne parlais pas de chaque GR mais répondais au fait du classement éventuel futur ou déjà réalisé d'un chemin traditionnel en tant que GR. La création de l'esprit dans ce cas se borne juste à la nomenclature en tant que GR (même su dans le détail, pour faire valoir ses droits, la FRPP va vouloir modifier légèrement ce chemin en selon ses propres critères. Un GR ne se suit pas exactement à la lettre de toute façon, parfois on se demande si certains détours ne sont pas faits uniquement pour en faire quelque chose d'unique, alors que rien ne justifie ce détour, pas même un attrait particulier,ou alors juste pour répondre à des arrangements locaux (voire mercantiles) afin de passer à proximité visible d'un gite, d'un hôtel, d'un camping, etc. même si pour y aller le chemin n'a rien de fantastique ou réemprunte la voie publique : est-ce encore un circuit de randonnée ou même de balade? De plus tous les GR labellisés n'ont pas obtenu le label avec la nécessité qu'il existe un programme de protection et d'entretien sur toute leur longueur. Une petite partie méritait le classement même même sans ce classement, cela serait resté un circuit de randonnée intéressant, qui a fait l'objet d'entretien ou de protection avant même que la FFRP s'en occupe. L'ennui ici c'est que la FFRP veut s'approprier tous les circuits existants les plus intéressants en son nom, au mépris des autres assos et collectivités locales qui peuvent vouloir une plus grande ouverture et qui depuis bien plus longtemp s'occupent elles-mêmes de la protection des lieux. Et ce n'est pas parce qu'une collectivité ou une asso demande le classement d'un circuit (surtout pour en faire la promotion et faire venir du monde), que cela implique un transfert de propriété à la FFRP. La FRPP n'a pas de monopole légal sur les chemins de France, et même si c'était le cas, la loi lui imposerait de rendre ses données cartographiques publiques ou ouvertes, car elle emprunte largement le domaine public. Le 29 décembre 2012 15:35, Matthias Dietrich eiger@gmail.com a écrit : Le 29 décembre 2012 12:34, Philippe Verdy verd...@wanadoo.fr a écrit : Tout à fait d'accord. Ce genre d'appropriation exclusive des droits communs des autres est un abus qui ne doit pas être toléré. Même si la mention GR ne figure pas dans la base (si on admet alors que c'est juste un label propriétaire, que seule la FFRP peut décerner, il restera que ces chemins ne lui appartiennent pas, et qu'ils auront été construits/balisés et relevés sur le terrain par d'autres). Sinon demain je déclare que les autoroutes françaises m'appartiennent parce que je vais décider de les appeler toutes autostrades avec ma propre numérotation. En quoi cela devrait changer le droit de mentionner les autoroutes existantes ? Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. Ton analogie n'est pas correcte : ce n'est pas un problème de nomenclature. Tu peux renommer les GR si tu veux, tu éviteras simplement l'emploi de la marque déposée GR. Le cœur du problème, c'est l'itinéraire en lui-même (le fait de suivre une liste précise de chemins ou de tronçons de chemins). L'itinéraire en lui-même peut être revendiqué comme œuvre de l'esprit. Après est-ce que chaque GR est une œuvre de l'esprit de la FFRP ? Seul la justice pourrait répondre. C'est bien là qu'est l'incertitude concernant cette histoire de GR. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Et tu fais comment pour distinguer les cas où il y a plusieurs numéros de référence, provenant parfois même de la même source, mais pour des usages différents ? Prenons le cas des régions françaises, on a un code ISO 3166-2, un numéro INSEE, plusieurs numéros SIREN (pour les différentes collectivités locales qui gèrent le même territoire), si on continue on aura aussi des codes FIPS, des régions académiques, des régions postales, ou pour les immatriulations automobiles, les régions militaires et de défense, les régions aériennes... Et on a aussi les codes NUTS. Le 29 décembre 2012 17:19, sly (sylvain letuffe) li...@letuffe.org a écrit : Hello, Je rebondis tardivement sur : http://lists.openstreetmap.org/pipermail/talk-fr/2012-November/051162.html Bien que l'avis fût unanime, et que mes chances de convaincre soient faibles, je vais quand même argumenter mon désaccord. Plutôt que de radoter (une fois de plus) je déterre des archives de Mars 2009 où j'exposais déjà mon avis préférentiel pour la tag ref plutôt que ref:INSEE ici : http://lists.openstreetmap.org/pipermail/talk-fr/2009-March/007604.html Mon avis, que j'ai jusqu'a présent maintenu, de préférer le tag ref dès que c'est possible concernait déjà les communes, mais s'affirme tout autant pour les départements. Je vais essayer de faire court : Ma préférence est d'opter pour un format : ref=73 + source:ref=INSEE au lieu de ref:INSEE=73 La raison en est l'uniformité mondial donc l'utilisation compatible dans les outils. De même qu'on ne choisi pas * name:en_français=tata mais name=tata * highway:français=autoroute mais highway=motorway Je pense que l'on devrait aussi utiliser ref=X et pas ref:Y=X Il y a 4 ans, je n'avais aucun exemple concret pour montrer le défaut de notre approche, maintenant j'ai nominatim. Nominatim cherche sur le tag ref et ne cherche pas sur ref:INSEE, démo : Un français moyen connait son département par son numéro, ça lui permet La demande suivante : http://nominatim.openstreetmap.org/search.php?q=73,france qui trouve, comme attendu par certains, la savoie en revanche : http://nominatim.openstreetmap.org/search.php?q=974,france ne trouve pas la réunion * pas plus que : http://nominatim.openstreetmap.org/search.php?q=73065,france ne trouve chambéry (dont le code INSEE est 73065) * Les mauvaises langues diront que c'est à cause des relations bizarres et tout ça mais que sinon ça aurait marché, mais en fait non, je n'ai pas exploré intégralement le code de nominatim, mais les ref:INSEE ne sont très certainement pas prises en compte et c'est pour ça que la réunion, qui n'a pas ref=974 ne sort pas de la recherche, alors que la savoie, qui a ref=73 elle sort. -- sly (sylvain letuffe) ___ 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] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Il ne serait pas illogique d'avoir un ref par défaut, et d'autres ref:xxx avec un éventuel doublon comme on le fait pour name name:xx Cela permet un usage par défaut par les outils non spécialisés (Nominatim est effectivement un bon exemple), et aussi par des outils spécialisés qui connaissent le principe du COG. ref=73 + ref:INSEE=73 ne me choquerait donc pas du tout. -- 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] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Le samedi 29 décembre 2012 18:00:54, Christian Quest a écrit :
ref=73 + ref:INSEE=73 ne me choquerait donc pas du tout.
ça me choquerait un peu moins, mais la redondance, c'est quand même pas
l'idéal non ?
Je maintiens ma proposition, (qui n'empêche en rien d'avoir d'autre ref jugées
non principales) style :
ref=73
ref:source=INSEE
ref:NUTS=X
ref:CHATAIGNES=Z
ref:SIREN=T
Une version de malade de la normalisation pour INSEE pourrait être :
ref:INSEE={{redirection|ref}}
--
sly (sylvain letuffe)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Mais alors pas ref:source=INSEE, mais source:ref=INSEE. Comme on peut avoir aussi source:population=COG / INSEE. Les sources sont toutes dans source:*=*. Mais ce que tu indiques dans ref:*=* doit être un identifiant unique, et ref:source=INSEE ne sera pas unique ! L'ennui de ref=73 c'est que c'est très peu sélectif dans la base : pour savoir ce que cela désigne il faut regarder tout un tas d'autres attributs et savoir ensuite comment l'interpréter selon le pays (et pas sûr que ref:source=INSEE soit très parlant comme critère). Je pense que ref:base=identifiant ou ref:code pays:base=identifiant (pour les bases externes non gouvernementales ou de portée non nationale ou pas intégrée à des normes internationales) reste le modèle préférable à un ref=* qui sert à désigner des tas de trucs très différents (des routes, des parcs régionaux, etc...) Note que les codes postaux sont aussi des réfs externes mais on les a mis plutôt maintenant dans addr:postcode (parce que cela sert au schéma international des adresses postales ; un alias est aussi postal_code=* voire zip_code=* trouvé parfois aux USA). Mais il n'est pas impossible qu'avec la multiplication des acteurs postaux, ceux-ci ne développent pas pour leur propre compte leur propre codification postale (pour leurs centres logistiques et de distribution ou collecte). Pour l'instant même avec la concurrence postale, les codes postaux français sont restés uniques (c'est peut-être du ressort de l'ARCEP en France de maintenir ce fichier pour tout le monde au lieu de La Poste comme avant). Mais je ne garantirait rien hors de France ou d'Europe. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Bonjour *Je n'exprime que mon avis d'après ce que j'ai compris et mes recherches.* C'est quoi le problème : - Utiliser la marque « GR » Lettre blanche sur fond rouge ? - Utiliser le symbole Double rectangle horizontale blanche en haut rouge en bas ou - Tracer les parcours composantes d'un itinéraire de type « GR » Pour la marque, oui, je pense qu'OSM ne doit pas l'utiliser car c'est une marque encore soumis au droit à la propriété intellectuelle tel que décrit. Il en est de même pour GR de pays et PR avec leurs figures et symboles respectifs. D'ailleurs ces termes sont accompagnés d'un « ® » sur le site de la FFRP. De même le terme sentier de grande randonnée est également une marque soumis aux mêmes droits que précédemment. Mais pas sentier pédestre, ni Sentier de randonnée. chemin de randonnées serait susceptible de l'être, mais un spécialiste du droit PI doit voit ce qu'il en est. Maintenant l'association des caractères formant les termes « GR » « GR de Pays » et « PR » semble n'être soumis à aucune protection, là aussi un spécialiste pourrait nous répondre. Dans les produits et services soumis à la protection de la marque « GR » on y trouve : « services d'organisation, de création et de gestion d'itinéraires de randonnées ; » Qu'est-ce qui est entendu sous ce service et produits ? On y trouve également : « édition sur tout support, notamment de livres, d'imprimés, brochures, numérisés ou non, interactifs ou non. » Tout ceci pour dire que je n'apporte pas de solution, mais des suggestions ou des ébauches d'idées qu'il faut creuser, pour éviter la suppression de tous éléments soumis à la protection de la FFRP, pour trouver des solutions pour garder et tracer ces éléments de chemins offerts à la randonnée). *mes 2c€* -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Le 29 décembre 2012 18:16, sly (sylvain letuffe) li...@letuffe.org a écrit : Le samedi 29 décembre 2012 18:00:54, Christian Quest a écrit : ref=73 + ref:INSEE=73 ne me choquerait donc pas du tout. ça me choquerait un peu moins, mais la redondance, c'est quand même pas l'idéal non ? Ah l'idéal ;) On l'accepte bien pour name ! Si ça peut simplifier la réutilisation des data, c'est quand même préférable sinon on va avoir des ref:INSEE dans des ref:INSEE et aussi dans des ref si source:ref=INSEE... Au final tu as 2 tags dans les deux cas. -- 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] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
2012/12/29 David Crochet david.croc...@online.fr: Tout ceci pour dire que je n'apporte pas de solution, mais des suggestions ou des ébauches d'idées qu'il faut creuser, pour éviter la suppression de tous éléments soumis à la protection de la FFRP Bah. C'est pourtant assez clair. Tout ce qui appartient à la FFRP ne peut figurer dans OSM sans son accord. Chose que nous n'avons pas obtenu. Mais... il y a un mais : Si les marques déjà citées appartiennent bien à la FFRP, il faut encore répéter ici que les chemins et voies empruntées par ces itinéraires appartiennent au domaine public et peuvent figurer dans OSM (leur tracé, leur nom, etc). Seuls des itinéraires non originaux (même utilisés en tout ou partie par la FFRP) peuvent figurer dans OSM. Le droit d'auteur protège la création (qu'on qualifie aussi d' oeuvre originale), rien d'autre. Ce qui veut dire qu'avant de publier un itinéraire dans OSM, il faut vérifier qu'il est libre de droit ou qu'on a l'autorisation de son auteur ou celui qui en possède les droits, FFRP ou autre, y compris les collectivités locales. Si des GR utilisent des bouts d'itinéraires plus anciens, comme le chemin de Stevenson ou le chemin Henri IV, on peut les mettre dans OSM à condition de ne pas utiliser les termes GR ou PR, etc, de la FFRP et qu'on est sûr qu'ils ne sont pas couverts par d'autres droits d'auteurs. Maintenant, il faut aussi se poser la question de la pertinence à mettre des itinéraires dans OSM, surtout s'ils n'ont aucune visibilité sur le terrain (aucun panneau signalétique). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets
Tu peux m'ajouter dans les contre. On 28 Dec 2012 21:47, Pieren pier...@gmail.com wrote: 2012/12/28 JB jb...@mailoo.org: C'est marrant, je ne me souviens pas avoir vu de majorité se dégager de la discussion sur les tirets et les trait d'union… Pieren avait certes sa majorité personnelle avant de lancer la discussion, mais ne semblait clairement pas majoritaire après les réponses. En ne comptant que les avis clairement exprimés: Pour: teuxe Philippe Verdy JB Mikael Cordon clansco Contre: Pieren Sly vdct Christian Quest Vladimir Vyskocil Jean-Francois Nifenecker Jean-Marc Liotier (pour le tag name) Plus deux avis peu clairs si ce n'est en faveur de la cohérence. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref ou ref:INSEE pour les départements (et les =?iso-8859-1?q?r=E9gions?=)
Le samedi 29 décembre 2012 21:32:29, Art Penteur a écrit : Je suis à fond pour. Les vieux briscards* d'OSM n'ont pas changé d'avis à ce que je vois ;-) : http://lists.openstreetmap.org/pipermail/talk-fr/2009-March/007611.html * Rien de péjoratif -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Il peut y avoir un intérêt à matérialiser les GR, car sur le terrain, ils sont clairement identifiés. Mais comme GR est une marque déposée ... Comme déjà indiqué, le GR ne sont que l'assemblage de chemin existants (dans la très grande majorité des cas). Ces chemins sont ouverts au public, donc rien ne nous empêche de les mettre dans OSM (sans l'indication GR bien évidement ). L'assemblage en GR étant laissé à l'initiative du lecteur et de son topoguide. Le 29/12/2012 19:38, Pieren a écrit : 2012/12/29 David Crochet david.croc...@online.fr: Tout ceci pour dire que je n'apporte pas de solution, mais des suggestions ou des ébauches d'idées qu'il faut creuser, pour éviter la suppression de tous éléments soumis à la protection de la FFRP Bah. C'est pourtant assez clair. Tout ce qui appartient à la FFRP ne peut figurer dans OSM sans son accord. Chose que nous n'avons pas obtenu. Mais... il y a un mais : Si les marques déjà citées appartiennent bien à la FFRP, il faut encore répéter ici que les chemins et voies empruntées par ces itinéraires appartiennent au domaine public et peuvent figurer dans OSM (leur tracé, leur nom, etc). Seuls des itinéraires non originaux (même utilisés en tout ou partie par la FFRP) peuvent figurer dans OSM. Le droit d'auteur protège la création (qu'on qualifie aussi d' oeuvre originale), rien d'autre. Ce qui veut dire qu'avant de publier un itinéraire dans OSM, il faut vérifier qu'il est libre de droit ou qu'on a l'autorisation de son auteur ou celui qui en possède les droits, FFRP ou autre, y compris les collectivités locales. Si des GR utilisent des bouts d'itinéraires plus anciens, comme le chemin de Stevenson ou le chemin Henri IV, on peut les mettre dans OSM à condition de ne pas utiliser les termes GR ou PR, etc, de la FFRP et qu'on est sûr qu'ils ne sont pas couverts par d'autres droits d'auteurs. Maintenant, il faut aussi se poser la question de la pertinence à mettre des itinéraires dans OSM, surtout s'ils n'ont aucune visibilité sur le terrain (aucun panneau signalétique). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets
Le 30/12/2012 à 07:45:07 +1100 Emilie Laffray emilie.laff...@gmail.com a écrit Objet: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets : Tu peux m'ajouter dans les contre. Tu peux m'ajouter aussi. -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
On peut les nommer IP (Itinéraire public) ou PIPI (promenade intensive protégée par des intérêts ...) Brainfart from Polyglot, Bonne année! 2012/12/30 piratebab pirate...@hotmail.com Il peut y avoir un intérêt à matérialiser les GR, car sur le terrain, ils sont clairement identifiés. Mais comme GR est une marque déposée ... Comme déjà indiqué, le GR ne sont que l'assemblage de chemin existants (dans la très grande majorité des cas). Ces chemins sont ouverts au public, donc rien ne nous empêche de les mettre dans OSM (sans l'indication GR bien évidement ). L'assemblage en GR étant laissé à l'initiative du lecteur et de son topoguide. Le 29/12/2012 19:38, Pieren a écrit : 2012/12/29 David Crochet david.croc...@online.fr: Tout ceci pour dire que je n'apporte pas de solution, mais des suggestions ou des ébauches d'idées qu'il faut creuser, pour éviter la suppression de tous éléments soumis à la protection de la FFRP Bah. C'est pourtant assez clair. Tout ce qui appartient à la FFRP ne peut figurer dans OSM sans son accord. Chose que nous n'avons pas obtenu. Mais... il y a un mais : Si les marques déjà citées appartiennent bien à la FFRP, il faut encore répéter ici que les chemins et voies empruntées par ces itinéraires appartiennent au domaine public et peuvent figurer dans OSM (leur tracé, leur nom, etc). Seuls des itinéraires non originaux (même utilisés en tout ou partie par la FFRP) peuvent figurer dans OSM. Le droit d'auteur protège la création (qu'on qualifie aussi d' oeuvre originale), rien d'autre. Ce qui veut dire qu'avant de publier un itinéraire dans OSM, il faut vérifier qu'il est libre de droit ou qu'on a l'autorisation de son auteur ou celui qui en possède les droits, FFRP ou autre, y compris les collectivités locales. Si des GR utilisent des bouts d'itinéraires plus anciens, comme le chemin de Stevenson ou le chemin Henri IV, on peut les mettre dans OSM à condition de ne pas utiliser les termes GR ou PR, etc, de la FFRP et qu'on est sûr qu'ils ne sont pas couverts par d'autres droits d'auteurs. Maintenant, il faut aussi se poser la question de la pertinence à mettre des itinéraires dans OSM, surtout s'ils n'ont aucune visibilité sur le terrain (aucun panneau signalétique). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] ODbLライセンスユースケース翻訳のお知らせ
木田です。コメントが遅くなりました。 無償と自由の区別は日本語として明確に区別すべきとのご指摘、 大変ありがとうございます。 1. 序章・第4パラグラフ この場合は無償というより、アクセス可能な状態にするという 意味合いが強いと思いますので「自由」の表現が良さそうです。 いいださんご提示の下記案でwikiを修正します。 * ただし、OSMを利用した派生データベースは、誰かからデータ内容の開示を求められた場合、その開示が妨げられない状態にしておくことが求められます。 2. ケース4「ライセンス要件：」の部分 the requirement to make the derivative database available free こちらも同様に、アクセス可能にするという意味合いが強いため、 「自由」のほうが妥当と思いました。 同様に下記案で修正します。日本語らしい文章で大変助かります。 * 派生データベースを引き続き自由なデータとして配布できるようにするため、 サードパーティ製のデータ利用条項とODbLのライセンス条項の間で齟齬が生じないよう、事前に確認する必要があります。 Kida 2012/12/25 17:47、Satoshi IIDA nyamp...@gmail.com のメッセージ: いいだです。 ユースケース翻訳、おつかれさまです！ これからいろいろな方面で利用されるにあたって、たいへん役に立つ資料かと思います。 1. 序章・第4パラグラフ ここは難しいですねｗ 文章が短いので、前に出てきた言い回しを短縮しただけ、にも見えます。 その場合、無償で、でも合っている気がします。 ただし、無償で、だとタダ配布限定ですが、 「自由な」だと、開示に際する実費相当くらいを要求者に請求することは許される印象があります。 本質的には「開示できる状態にしておく」ことが重要なので、 ここは意味合いとして「自由」なのかなぁとおもいます。 変更案としては、こんなかんじでどうでしょう？ * ただし、OSMを利用した派生データベースは、誰かからデータ内容の開示を求められた場合、 その開示が妨げられない状態にしておくことが求められます。 2. ケース4「ライセンス要件：」の部分 the requirement to make the derivative database available free 文章の大筋として「サードパーティのデータと混ぜる前に、 そのサードパーティのデータが 無料で 配布されているものだとしても、 ちゃんと配布条件を確認して、自由なライセンスのデータと混ぜてしまった後に ちゃんと自由に配布が可能であり続けられるかを確認してね？」っていう 意味合いかと思います。 なので、こんなかんじではどうでしょうか。 噛み砕きすぎかな？ You must ensure that the license requirements of the third party data do not conflict with the license conditions of ODbL, for example the requirement to make the derivative database available free. * 派生データベースを引き続き自由なデータとして配布できるようにするため、 サードパーティ製のデータ利用条項とODbLのライセンス条項の間で齟齬が生じないよう、事前に確認する必要があります。 2012年12月25日 11:48 Yoichi SEINO say.n...@gmail.com: 清野です。 早速読ませていただきました。 大変な作業だったと思います。ありがとうございます。 さて、読んでいて少し気になったところが幾つかありましたので、コメントさせて頂きます。 もし間違っていたらご指摘下さい。 書き換えてしまっても良かったのですが、一応こちらに投稿させていただきました。 本来ならWiki当該ページのDiscussionのページで議論すべきなのかもしれませんが、 こちらのほうが訳者も皆さんも見ているかと思いましたので。 必要なら下記の議論を転載しておきます。 1. 序章・第4パラグラフ 「ただし、OSMを利用した派生データベースは、誰からの要求に対しても無償で利用可能にすることが求められます。」 の部分の『無償』の部分は原文を見ると 「but any derivative database from OSM must be available to anyone who asks, for free.」 となっています。 原文のその前の一文で、「無償」という表現をする場合には 「do not have to pay for your use of OSM data」 とか 「free to charge」 という表現になっておりますので、この部分の「free」は『自由』ではないかと思います。 そうでないと、このパラグラフの内容が矛盾してしまうと思います。 こちらのブログエントリーでも書かせていただきましたが、 http://d.hatena.ne.jp/Say-no/20121220/1355934209 英語の場合は「無料」も「自由」も「Free」という単語になってしまうので致し方ない (なので、 http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AA%E3%83%BC%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2#.E8.87.AA.E7.94.B1.E3.81.AA.E3.82.BD.E3.83.95.E3.83.88.E3.82.A6.E3.82.A7.E3.82.A2.E3.81.A8.E3.80.81.E7.84.A1.E5.84.9F.E3.81.AE.E3.82.BD.E3.83.95.E3.83.88.E3.82.A6.E3.82.A7.E3.82.A2 ここでも書かれているように、「free as in free beer」と「free as in free speech」の例がよく示されるわけですが…) ようなのですが、 日本の場合はきちんと「無料」と「自由」を単語で区別できますので、 それはきちんと使い分けるべきだと思います。 まだまだ日本人の中にはこの部分がごっちゃになっている人が多いので。 2. ケース4「ライセンス要件：」の部分 ここも1.と同じく、「例えば、派生データベースを無償で入手可能とするライセンス要件などです。」の部分の「無償」は「自由」のような気がします。 とりあえず気になったのは以上です。 よろしくお願い致します。 2012年12月24日 22:12 KazumiK kaz...@osmf.jp: 木田です。 ODbLライセンスユースケースの日本語翻訳を実施いたしました。 OSMデータを用いたサービスをお考えの際、ODbLに準拠するために どのようなことをすればよいかが簡潔に記述されております。 下記のリンクをご覧ください。 http://wiki.openstreetmap.org/wiki/JA:License/Use_Cases 翻訳内容が分かりにくい等あるかと思いますので、 ぜひ改訳にご協力いただけますと幸いです。 ___ 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 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ 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: [OSM-ja] [ゆる募] LODチャンレンジの勉強会
大和田さんへ (2012年12月26日 01:10), 大和田 健一 wrote: LODチャンレンジに OSM もデータを提供しています。 http://lod.sfc.keio.ac.jp/challenge2012/resource_usage.html#osmfj 「Databases and data access APIs」を読んで始めてね。 http://wiki.openstreetmap.org/wiki/Databases_and_data_access_APIs となっていますが。 素人には手が出ないですね。(^^; LODチャレンジで、OSMのデータを活用すると考える場合、 １）APIでデータを検索条件などを示しながら（元データを）取得する。 ２）OpenDataの特性を生かし、RDBMSや、NoSQLデータベースに格納し、分析する。 のふたとおりあるとおもいます。 本ページのAPIやソフトウエアの紹介は、（１）（２）の双方について記述されています （１）では、XAPIを使うのがよいとおもうのですが、Botが情報を集めていくような 用途に有効です。テーマを持って、地理データをクロールして、新しい価値を集めてください。 たとえば、世界の寺院等の位置を抽出して、アート作品を構成するとか。 （２）では、よりディープなデータ分析ができますので、Business Intelligenceと 呼ばれるような技術分野の活用が期待されます。 他のOpen Dataと組み合わせての検索や価値創出を行なって欲しいという事になります。 （２）で、オーソドックスな方法は、OSMのPlanet情報を PostGISにロードし（高性能PCで７０−１００時間くらいかかるかと） SQLで処理するアプリケーションを書いて見るかんじですね。 最近風であれば、MongoDBやCouchDBに格納して、スケールアウト型で処理したり、 Hadoopで処理したりしても素晴らしいかもしれません。 せっかくデータを提供しているので、何か作ってみたいと思っています。 誰か「サルでもわかる勉強会」とか開催してくれないかな。 OSMのデータをLOD的に活用するとなると、サルでもわかるとは行かないような。 主題図の背景地図につかうだけでは、LOD的ではないので面白くないですね。 追伸 「横浜市芸術文化振興財団」もデータを提供しています。 こちらの勉強会は明日12月26日にやります。 http://atnd.org/events/35256 たとえば、「横浜市芸術文化振興財団」 の場所情報と、OSMのデータを結合して、 「横浜市芸術文化振興財団」の場所情報ではわからない 、その場所の半径５００ｍ以内の 駐車場の数や収容台数を分析してみる、みたいなのが、LOD的ですね。 イベントの人数と駐車場問題の関係とか、なにかわかるかもね。 OSMでは、parkingのタグで、有料・無償、収容台数などのタグがあり、 分析できるかもしれません。 これをやるには、XAPIで、タグを検索することで、必要な情報のみ 抽出できるでしょう。 http://wiki.openstreetmap.org/wiki/JA:Xapi こんな感じでしょうか？ ミウラ ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] parcel data in OSM
Hi, On 29.12.2012 03:22, Russ Nelson wrote: Here in the US where you aren't allowed to trespass on private property except on certain conditions, these line[s] in some government database MATTER to mappers and to map users. But surely there must be something on the ground that tells you where you can go and where you can't? Else how would people have evaded being shot in pre-satnav times? It may be different where you live. That doesn't mean you should advocate for us to map badly. Mapping, in OSM, has a large component of surveying. Mapping badly is mapping without survey. It is possible that you *need* those lines in a government database for whatever outdoor activity you are planning, and it might indeed be a good idea for a map producer to include them in his map. But that doesn't mean it makes sense to include it in the OSM database. Too many people think that anything they want to see on a map, must go into OSM. That is wrong. Anything that should be the subject of crowd editing must go into OSM; anything else should not. Un-surveyable data is a nuisance for everyone working with OSM data; it disempowers the mapper who works with the data because they have to simply accept it as a fact if they cannot see it on the ground. Adding such data to OSM sends the message to mappers: If there's a mismatch between OSM data and what you see on the ground, better don't mess with the OSM data because surely someone has put that there for a reason. This is what leads to bad mapping. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
Hi, On 29.12.2012 05:38, Russ Nelson wrote: The moment it makes its way in to OSM it becomes incorrect. There is *absolutely* no way to improve the data once it's in OSM, so it should not be in OSM. Period. That's a great theory, but I don't think many people subscribe to it. I think that is more than a theory. Weren't you the one who proposed to import some kind of park boundaries, years ago, and implement mechanisms to make the geometry un-changeable - reasoning that any change being made by mappers could only be for the worse? The idea didn't get a very warm reception then, and I don't see why things should have changed. OSM is not a geodata delivery vehicle that you should abuse to publish third-party GIS data. I know it is tempting - so many county GIS departments, each with their own data collection, difficult to discover and use - but it is a role that OSM cannot, and should not attempt to, fulfil; not least because the sheer amount of such data would dwarf that which we have surveyed and which we can reasonably hope to care for. If you want a geodata delivery infrastructure, set up a separate service - based on OSM technology if you want - and collect third-party data there. Mix it with human-surveyed and curated OSM at the rendering stage if you want. There is no point in having this discussion again unless you're going to bring up something new. Exactly. and lots of opinions. You're welcome to express yours, but you're not welcome to claim it is or should be the ruling opinion. It is, and should be, the ruling opinion that data that cannot be sensibly edited by mappers shouldn not be in OSM. OSM is for editing, not for mirroring stuff that is edited elsewhere. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
On Fri, Dec 28, 2012 at 11:38 PM, Russ Nelson nel...@crynwr.com wrote: OSM is a big tent with room for lots of data and lots of opinions. You're right Russ, that there are a lot of strong opinions in the group, and that there's room for everyone's opinion in this matter. At the same time, when we are talking about certain topics that have a national or global effect, there needs to be discussion and overall consensus. You're welcome to express yours, but you're not welcome to claim it is or should be the ruling opinion. This is why I've created the Import Committee, to allow for imports to be discussed on an individual basis, and to help create consensus for what imports we want, and then help move those into OSM in a fast and organized way. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
Frederik Ramm writes: I think that is more than a theory. Weren't you the one who proposed to import some kind of park boundaries, years ago, and implement mechanisms to make the geometry un-changeable - reasoning that any change being made by mappers could only be for the worse? Yes, I did, and I was wrong. It *does* make sense to import such boundaries into OSM and let people edit them. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
On 2012-12-29 12:11AM, Frederik Ramm wrote: Hi, On 28.12.2012 22:16, Jason Remillard wrote: So the question is, what should the exact criteria be for including an open space parcel in OSM. Consider some of the various types of property. I'd say anything that is observable on the ground is fine to map. It's also valuable to map access/restrictions. I love discovering local areas that are open to the public. Someone also pointed out that access=yes encourages trail mappers. -- Jason ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
Un-surveyable data is a nuisance for everyone working with OSM data; except for those mappers which it empowers by telling said mappers where they are allowed to survey, and probably others. it disempowers the mapper who works with the data because they have to simply accept it as a fact if they cannot see it on the ground. Adding such data to OSM sends the message to mappers: If there's a mismatch between OSM data and what you see on the ground, better don't mess with the OSM data because surely someone has put that there for a reason. Now that just doesn't make sense. If it's something that cannot be seen on the ground then there cannot be a mismatch with what people see on the ground. I believe there is extremely broad agreement about including certain kinds of lines that cannot be seen on the ground, such as administrative boundaries. You are of course free to express your disagreement, but please be careful not to misrepresent the general consensus of the community. -- Jason ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data in OSM
On Sat, Dec 29, 2012 at 4:00 AM, talk-us-requ...@openstreetmap.org wrote: But surely there must be something on the ground that tells you where you can go and where you can't? Else how would people have evaded being shot in pre-satnav times? Actually, not. Sometimes there is a a 'No Trespass or No Hunting sign. But every local jurisdiction is different, and who does what where and when can be a fairly complex situation, a combination of both statute (laws) and custom / etiquette http://fwp.mt.gov/fishing/guide/access/streamAccess.html. If folks abuse the custom, it usually becomes statute. For instance, Montana allows public right of way down and alonghttp://fwp.mt.gov/fishing/guide/access/streamAccess.htmlmost flowing, non-intermittent waterways (below the high water line) for recreational purposes http://fwp.mt.gov/recreation/ethics/riverRecreation.html. In Washington State, similar rules apply to access along salt water, in the intertidal zone. New York City has privately owned public parkshttp://www.nyc.gov/html/dcp/html/priv/priv.shtml, where there has been disputes between neighbors and corporations about access times, activities permitted, etc. The point being, is that every locale is going to have features (and combinations of features) to give contest to some user's activity or use. And for that individual or community of users, if that feature(s) can't be added or isn't present, the map is 'broken'. If my purpose is to portray kayaking or combing routes along the washing coast, the low and high water line are critical - not having these simple pieces of information can actually be dangerous to the person viewing the map, because of the nature of the shoreline. If it's hiking / snow shoeing, while 10 ft contours would be overkill, the 500ft, 1000ft, 1500ft, 2000ft, etc. are critical because weather warnings are broadcast according to those levels. In the urban areas of Seattle, major areas are referred to by which 'hill' they are on. The first line in the OSM Wiki says *Welcome to OpenStreetMap, the project that creates and distributes free geographic data for the world. We started it because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways.* Adapting the some parts of the map content local conditions would seem to meet this philosophy, but I have been detecting a refrain that if it doesn't fit some current 'x-y-z' tradition / theme, go do it 'elsewhere'. Michael Patrick ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
