Re: [Talk-de] motorway_link mit ref taggen oder etwa nicht??? (war: Re: Trennzeichen bei Au fzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergä nzen))
Am 5. Juni 2010 02:18 schrieb steffterra steffte...@me.com: Der ref hat einen Bezug, wie sein Name schon sagt. Und der ist der logischste: der wohin er mich hinführt. Und zwar nicht nur die Auffahrt führt mich auf die Autobahn, sondern auch die Abfahrt führt mich auch auf die Landstraße. Deshalb konsequent für letzteres auch den ref der Landstraße setzen. Oder man macht es anders herum genauso konsequent: immer den ref dahin setzen, wo die Straße herkommt - doch wo führt uns das hin? (kleines Wortspiel). Meine Güte, es wurde doch bereits (er/ge)klärt, daß ref=* _nicht_ der Wörterbuch-Übersetzung (deiner Wahl) von reference entspricht, sondern einfach nur die Kurzbezeichnung angibt, unter der diese Route wenn du so willst *referenziert* wird. Im übrigen ist es kein Problem für einen Router, bei einem Abbiegehinweis einfach den Namen des _nächsten_ Stückchens Straße zu nennen, das einen solchen hat (in diesem Falle eine ref). Frag mal die Firma Garmin, beispielsweise. Wieso sollte eine Autobahn zwei verschiedene ref-Tags haben? Die A 3 kann nicht auch auf der A 7 sein. Ausnahme: motorway_links am Kreuz A 3-A 7 - aber das sind auch keine Autobahnen ;-) Die Antwort ist 42. http://www.openstreetmap.org/browse/way/4241623 Lass dich von der 23 nicht beirren. Das hat seine Richtigkeit. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Segway leihen
Am Montag 07 Juni 2010, 03:07:12 schrieb Johann H. Addicks: Am 06.06.2010 17:25, schrieb o...@tappenbeck.net: amenity = segway_rental ?? Und für den GPS-Verleih dann gpsr_rental? Und für den Werkzeugverleih diytool_rental? Der Bootsverleih dann pedalboat_rental? Warum nicht ein amentiy=rental_agency und rental=[bicycle|motorbike|car|truck|segway|pedal boat|...] +1 signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-lt] Lietuvos aerofotonuotraukos WMS
Sveiki, Kasiau, kasiau ir atkasiau... :) Nacionalin? ?em?s tarnyba prie ?em?s ?kio ministerijos yra sudariusi tokius du ORT10LT ortofotografinius ?em?lapius (nuotraukos darytos i? l?ktuvo). Vienas yra spalvotas 2005-2006 met?, o kitas senesnis yra nespalvotas 1995-2001 met?. Taigi prie reikalo, www.geoportal.lt portale N?T pak?r? to senojo nespalvoto ortofotografinio ?em?lapio WMS serveri. Galit ?sid?ti ? JOSM: http://www.geoportal.lt/services/public/ORT10LT_JB_WMS_test2/MapServer/WMSServer?request=GetMaplayers=0styles=format=image/pngversion=1.1.1; Manau tikrai vertas d?mesio, ypa? ten kur Yahoo! nieko gero... (Kaune pvz.) Ai?ku pai?yti pagal j? OSM kolkas NEGALIMA, bet manau b?tu verta ka?kaip susisiekti su N?T ir gal pavyktu gauti toki leidim?!? Strimgalviais gal ir nereikia j? u?pulti, bet pasiruo?us ir normaliai prista?ius OSM projekt? manau ?ansai b?tu visai neblogi. Paulius Puikios nuotraukos net ir mažų miestelių. Ir nespalvotos būtų puiku, nes ne daug kur infrastruktūra smarkiai pasikeitę per 10-15 metų. Gaila, kad (kol kas :)) NEGALIMA naudoti su OSM. ___ Talk-lt mailing list Talk-lt@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-es] Clasificación de colegios / Institutos
¡¡¡h!!!échales un vistazo... ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Clasificación de colegios / Institutos
El 06/06/2010, a las 20:49, Carlos Dávila escribió: ¡¡¡h!!!échales un vistazo... heepa! cabrín! el silencio hacía el olvido.. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-cz] tagování sídel
Dne 4.6.2010 14:06, MP napsal(a): Další příklad - podle wiki by měl town být 10-100 tis. obyvatel. Našel jsem spoustu obcí, které někdo označil jako town jen proto, že má k tomu místu vztah (možná tam bydlí), přestože obec měla sotva 1000 obyvatel a Rabštejn nad Střelou má asi 20 stálých obyvatel (+pár chalupářů), přesto má status města (ve středověku tam byl hrad a trochu větší osídlení, dnes tam moc lidí není, ale status města zůstal). Takových pidiměst (pod 1000 obyvatel) je víc, byť ne tak malých. Tam by zase asi nechtělo cpát do nich town, byť mají status města, protože jsou pak tyto pidiměsta vidět už od příliš velkého zoomu. To neni ovsem problem znaceni,ale problem renederu. Rabstejn je naprosto spravne town, a reneder si muze pouzit tag s poctem obyvatel (pokud bude). Stejne je to renederovany spatne, protoze casto vedle sebe existuje nekolik polozek town a jako napotvoru je pri odzoomovani renederovany to nejmensi z nich. Tudiz lepe je naucit mapnik brat ohled na pocet obyvatel a to s tim, ze pokud neni, tak ma dana obec rozhodne min obyvatel, nez ta, ktera ten pocet definovany ma. ani nemá status města. Ani většina měst, co máme označených jako town, toto nesplňuje. Jak rozhodnout tu hranici? Proto se to dělá podle toho, zda má u nás obec status města, pak je to town, jinak je to prostě village (včetně tzv. městysů). Toto přesně definuje značení a každý ví, jak to má udělat. Oproti stavu, kdy definujeme nějakou velikost - rozlohu/počet obyvatel apod. Možná by oficiální status (obec, město, městys, městská část, část obce) + počet obyvatel k nějakému dni šel docpat do dalšího tagu a pak podle něj případně přetagovávat (město + obyvatelé1000 - village), pokud vymyslíme pravidla podle kterých by to šlo dělat. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Dne 4.6.2010 18:35, Petr Morávek [Xificurk] napsal(a): Mike napsal(a): Ano suburb je nějaké předměstí, sídliště apod., což je ale také část města. Co třeba Dubeč? Je to část města nebo předměstí? To je taky taková vesnice, ale zároveň součást Prahy. Nebo co to vlastně je? Souhlasím s tím, že současné značení není ideální, ale nemáme lepší. Ano, tohle je trochu subjektivní... kde je ta hranice mezi městskou zástavbou a kdy už je to vesnice. Ale pořád si myslím, že je lepší tagovat podle reálného charakteru zástavby (s tím, že se prostě ve sporných případech budou muset dohodnout mezi sebou lidi z dané lokality), než tagovat naprosto nesmyslně skupinu pár vesnických stavení jako suburb. Suburb jsou napr mestne casti Prahy nebo jinych mest, rozhodne to nejsou obce, ktere stoji samostatne (rekneme, ze rozlisovaci znameni = samostatna zacatek/konec obce cedule u silnice). Praha 10/Vrsovice/Stare Mesto/... jsou tudiz suburb, protoze jsou soucasti mesta Praha (nemaji svoje cedule zacatek/konek obce na silnicich). Pokud ponecháme place jen pro renderování, tak ho klidně můžeme definovat dle velikosti Velikost by neměla být tím primárním faktorem, k tomu slouží tag population. Pak taky musíme vymyslet zcela jiný tag, který definuje status obce. Já jsem pro, už jen proto, že v ČR se z úředního statutu obce/části obce nedá pro praktické účely vyvodit zhola nic. Navíc máme (statutární) města, městyse a obce, to jsou informace které je myslím dobré nějak do OSM dostat (nějak jinak než tag place :)). A nezbořit při tom hlavně adresy a kompatibilitu s jinými zeměmi. Ono to s tou kompatibilitou není nijak slavné, protože hodnoty tagu place se tak jako tak v každém statě přidělují jiným způsobem a skutečně většinou vyjadřují regionální důležitost sídla a charakter zástavby. Celý tenhle problém taky pramení z toho, že tu máme i úředně zavedeno několik naprosto rozdílných způsobů dělení... * správní: obce – části obce – základní sídelní jednotky díly – statistické obvody resp. obce – městské obvody/městské části – části obce díly – základní sídelní jednotky díly – statistické obvody * územní obec – katastrální území – územně technická jednotka – základní sídelní jednotka – statistický obvod * zmiňované adresy, které jsou tedy pěkný maglajz, protože... - č.p. je jedinečné v rámci části obce, nikoliv však v rámci městské části/obvodu - ty, jsou tvořeny díly (různých) částí obce - PSČ se přiděluje skupině dílů části obce, tzn. jedna část obce může mít více různých PSČ a jedno PSČ může zahrnovat území spadající pod nejen různé části obce, ale i pod různé obce Řekl bych, že tenhle chaos nějaké tagování všech částí obcí jako suburb vůbec nevyřeší. Pokud to někoho zajímá, tak doporučuju metodiku ze stránek ČSÚ: http://www.czso.cz/csu/rso.nsf/i/metodicka_dokumentace_registru_doc/$File/metodika%202009_v1.zip Osobně nevím, co se to vlastně má do správné adresy psát. Co se týče pošty, tak ta si to (většinou) pokud je správně aspoň PSČ nějak přebere... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Dne 5.6.2010 1:06, Petr Morávek [Xificurk] napsal(a): Mike napsal(a): Tak jak je to v současnosti, tak definování adres funguje docela dobře. Osobně to dělám takto: (MC Navi) 1. najdu všechny relace boundary s admin_level=8 2. najdu nody s tagem place=village/town/city (suburb ignoruju), pokud je jeho jméno shodné s relací 1 a je uvnitř, je to navigační bod, kam se naviguje pouze podle obce, pokud není 1 a je jen 2, tak jde jen o město bez definovaných adres bez definovaných adres? Tomu nějak nerozumím. 3. pro všechny pojmenované highway najdu, uvnitř které relace 1 se nachází, a to je ulice, je vždy jedinečná v rámci jedné obce, pokud není žádná, zahazuju 3. pro všechny adresní body hledám relaci 1, tím ho přiřadím ke městu, podle street najdu 3 a přiřadím Jestliže bod s place=* leží uvnitř relace boundary s admin_level=8 (ideálně s definovaným administrativním centrem), tak je celé rozpoznání bodu obce triviální záležitost, ne? A všechny zbylé body s tagem place jsou části této obce. Tento algoritmus nikde nepoužívá hodnotu tagu place. A (nejen) v ČR ty admin_level=8 máme kompletní... stále nevidím důvod proč označovat pár stavení ([1], [2]) jako suburb (což i ve vyhledávání podle nominatim na hlavní stránce osm je přeloženo celkem správně jako městská část). Osobně je mi označení vesnice, město, městys, statutární město úplně jedno. Jsem ale pro to, aby šlo podle place rozlišit to, jestli je vesnice součástí jiné nebo jde o samostatnou obec. Tak to funguje i jinde, takže není nutné dělat různé věci pro každý stát zvlášť. Skutečně? Já se teď díval třeba do Rakouska na oblast mezi českými hranicemi a Vídní - suburb používají výhradně pro části Vídně, a naprosto běžně mají více place=village,hamlet uvnitř jedné relace admin_level=8 (který označuje jejich ekvivalent obcí). Proč v seznamu měst mít plno vesniček, které tam nikdo hledat nebude? Pokud někdo jede na adresu, tak většinou ví, kam jede a jak je to značené. A na tomhle se taky neshodnem - ještě jsem např. neslyšel nikoho říkat, že bydlí v části obce Blansko, Hrochův Týnec; je to prostě Blansko a basta, konec konců takový je i nápis na ceduli při vjezdu do obce. Místní by se asi hodně smáli, kdyby se doslechli, že jsou v mapě zaneseni jako suburb (městská část, sídliště, předměstí, nebo jiný podobný překlad). Presne, ostatne i dopis se adresuje do Blanska. Suburb je proste mestska cast, rozhodne ne samostatna obec. Ostatne pod kterou obec administrativne patri se da zjistit z importovanych hranic. Pr: Teplice - suburb Trnovany, Prosetice, Retenice ... (kdysy samozrejme vsechno samostatne obce, ale aktualni stav je takovy, ze nemaji svoji znacku obce u silnic - jsou to Teplice). [1] http://www.openstreetmap.org/?lat=49.94671lon=15.93884zoom=17layers=B000FTF [2] http://www.mapy.cz/#mm=ztt...@sa=s@s...@ssq=blansko%2c%20chrudim@ss...@ssp=135941888_136180320_135970560_136205120@x=136552...@y=135460064@z=15 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Dne 5.6.2010 21:41, Petr Morávek [Xificurk] napsal(a): Petr Morávek [Xificurk] napsal(a): Pokud to někoho zajímá, tak doporučuju metodiku ze stránek ČSÚ: http://www.czso.cz/csu/rso.nsf/i/metodicka_dokumentace_registru_doc/$File/metodika%202009_v1.zip Mimochodem v tomto dokumentu jsou i dvě zajímavé kapitolky ohledně užívání dat. 1.4. Ochrana individuálních dat Registr sčítacích obvodů a budov neobsahuje skutečnosti, na něž se vztahuje ochrana individuálních dat dle zákona č. 89/1995 Sb., o státní statistické službě. 1.5. Externí využívání Registr sčítacích obvodů a budov ze zákona č. 89/1995 Sb., o státní statistické službě, v platném znění, je dle novelizace zákona zveřejněné ve Sbírce zákonů 2004, částka 25 ze dne 25. února 2004 veřejným seznamem. Dle novelizace zákona č. 230/2006 Sb., jsou údaje o počtu bytů v jednotlivých budovách veřejné a údaje o jednotlivých bytech jsou neveřejné. O vývoji registru je informováno prostřednictvím veřejné internetové služby na stránce http://www.czso.cz/csu/rso.nsf/i/registr_scitacich_obvodu Já si to vykládám tak, že je možné ty data bez problémů importovat do OSM. Příp. se můžeme s odkazem na tento text ujistit přímým dotazem na ČSÚ, z kontaktů mi přijde jako nejvhodnější: Vzhledem k tomu ze ta data jsou nejspis pouzita na wiki, ze ktere by je bylo mozne nejspis i vygrabovat ... Distribuce výstupů z registru Lenka Šilhanová, vedoucí oddělení pro poskytování elektronických výstupů tel: 274 053 115 e-mail: lenka.silhan...@czso.cz Co vy na to? Mám tam napsat, nebo se najde vhodnější člověk (třeba někdo, kdo něco _ví_ o předešlé komunikaci :))? Zdraví, Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Dne 5.6.2010 21:41, Petr Morávek [Xificurk] napsal(a): Petr Morávek [Xificurk] napsal(a): Pokud to někoho zajímá, tak doporučuju metodiku ze stránek ČSÚ: http://www.czso.cz/csu/rso.nsf/i/metodicka_dokumentace_registru_doc/$File/metodika%202009_v1.zip Mimochodem v tomto dokumentu jsou i dvě zajímavé kapitolky ohledně užívání dat. 1.4. Ochrana individuálních dat Registr sčítacích obvodů a budov neobsahuje skutečnosti, na něž se vztahuje ochrana individuálních dat dle zákona č. 89/1995 Sb., o státní statistické službě. 1.5. Externí využívání Registr sčítacích obvodů a budov ze zákona č. 89/1995 Sb., o státní statistické službě, v platném znění, je dle novelizace zákona zveřejněné ve Sbírce zákonů 2004, částka 25 ze dne 25. února 2004 veřejným seznamem. Dle novelizace zákona č. 230/2006 Sb., jsou údaje o počtu bytů v jednotlivých budovách veřejné a údaje o jednotlivých bytech jsou neveřejné. O vývoji registru je informováno prostřednictvím veřejné internetové služby na stránce http://www.czso.cz/csu/rso.nsf/i/registr_scitacich_obvodu Já si to vykládám tak, že je možné ty data bez problémů importovat do OSM. Příp. se můžeme s odkazem na tento text ujistit přímým dotazem na ČSÚ, z kontaktů mi přijde jako nejvhodnější: Distribuce výstupů z registru Lenka Šilhanová, vedoucí oddělení pro poskytování elektronických výstupů tel: 274 053 115 e-mail: lenka.silhan...@czso.cz Co vy na to? Mám tam napsat, nebo se najde vhodnější člověk (třeba někdo, kdo něco _ví_ o předešlé komunikaci :))? Zdraví, Petr Zmíněný registr je samozřejmě z hlediska AZ veřejně přístupným rejstříkem (§3), možno použít bez neveřejných údajů zcela bez problémů, na to není potřeba ani svolení, ani složitý právní výklad. MK ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Bonjour, Mappant autour de Cognac, je retravaille actuellement le fleuve Charente dans ce coin. En effet le fleuve Charente est actuellement composé de petits polygones issus d'un import 'PGS (?) non contiguë (voir exemple (1)) J'ai donc commencé a reconstruire correctement le fleuve à Cognac en traçant le centre du fleuve avec un way (waterway=river) et en transformant les petits polygones isolés en riverbank en traçant les rives du fleuve avec un polygone fermé et en mettant les îles, le tout dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça commence a être lourd maintenant de j'étend ce schéma au delà de la ville de Cognac (2) Donc : les rives en way (name=La Charente, waterway=water_bank et natural=water) les iles en way (place=island) le tout regroupé en relation type=multipolygon et les rives en outer, les iles en inner. Mon soucis est donc que maintenant le multipolygon commence a devenir grand et que si je continu ce schéma pour tout le fleuve je sais pas trop comment ça va se passer avec JOSM... Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le pourtour, c'est étrange et pas très lisible (2). (1) http://www.openstreetmap.org/?lat=45.6396853923798lon=-0.0683856010437012zoom=15 (2) http://www.openstreetmap.org/?lat=45.70458lon=-0.31494zoom=15layers=B000FTF -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 11:02:49, Pierre-Alain Dorange a écrit : Bonjour, Mappant autour de Cognac, je retravaille actuellement le fleuve Charente dans ce coin. En effet le fleuve Charente est actuellement composé de petits polygones issus d'un import 'PGS (?) non contiguë (voir exemple (1)) J'ai donc commencé a reconstruire correctement le fleuve à Cognac en traçant le centre du fleuve avec un way (waterway=river) et en transformant les petits polygones isolés en riverbank en traçant les rives du fleuve avec un polygone fermé et en mettant les îles, le tout dans une relation multipolygone. Il y a de quoi s'amuser ! ;) Ca fonctionne plutôt bien, mais ça commence a être lourd maintenant de j'étend ce schéma au delà de la ville de Cognac (2) Les multipolygons sont là pour faire du multipolygon... et pas le fleuve lui même. Donc il faut l'utiliser pour les îles. Mais tu peux faire plusieurs multipolygon pour le même fleuve. Ensuite tu peux rassembler les différents éléments du fleuve dans un autre relation de type=waterway http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau Donc : les rives en way (name=La Charente, waterway=water_bank et natural=water) Non, il ne faut pas de natural=water, pour un fleuve c'est du waterway=riverbank les iles en way (place=island) Tu peux aussi rajouter des natural= ou des landuse= et tout ce qui peut être intéressant. le tout regroupé en relation type=multipolygon et les rives en outer, les iles en inner. Ok Mon soucis est donc que maintenant le multipolygon commence a devenir grand et que si je continu ce schéma pour tout le fleuve je sais pas trop comment ça va se passer avec JOSM... Diviser pour régner Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le pourtour, c'est étrange et pas très lisible (2). Regardes ta relation là, il te manques des îles : http://www.openstreetmap.org/browse/relation/398715 Fred ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 à 11:02 +0200, Pierre-Alain Dorange a écrit : Bonjour, Mappant autour de Cognac, je retravaille actuellement le fleuve Charente dans ce coin. En effet le fleuve Charente est actuellement composé de petits polygones issus d'un import 'PGS (?) non contiguë (voir exemple (1)) J'ai donc commencé a reconstruire correctement le fleuve à Cognac en traçant le centre du fleuve avec un way (waterway=river) et en transformant les petits polygones isolés en riverbank en traçant les rives du fleuve avec un polygone fermé et en mettant les îles, le tout dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça commence a être lourd maintenant de j'étend ce schéma au delà de la ville de Cognac (2) Donc : les rives en way (name=La Charente, waterway=water_bank et natural=water) les iles en way (place=island) le tout regroupé en relation type=multipolygon et les rives en outer, les iles en inner. Mon soucis est donc que maintenant le multipolygon commence a devenir grand et que si je continu ce schéma pour tout le fleuve je sais pas trop comment ça va se passer avec JOSM... Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le pourtour, c'est étrange et pas très lisible (2). Le lit des fleuves et rivières en waterway=river + name Les rives en *plusieurs* polygones waterway=riverbank (sans nom) de taille raisonnable. Les îles en multipolygone inner associé au riverbank en rôle outer Le nom de l'île qui s'affiche sur le contour est peut-être un bug de rendu lié a l'absence de balise natural ou landuse. Peut-être vaut il mieux mettre le nom sur un *nœud* place... Par ailleurs, je n'aime pas voir les rivières en layer=-1, ça ne me parait pas correspondre à la réalité. Librement, ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 6 juin 10 à 11:30, Frédéric Rodrigo a écrit : J'ai donc commencé a reconstruire correctement le fleuve à Cognac en traçant le centre du fleuve avec un way (waterway=river) et en transformant les petits polygones isolés en riverbank en traçant les rives du fleuve avec un polygone fermé et en mettant les îles, le tout dans une relation multipolygone. Il y a de quoi s'amuser ! ;) En effet. Ca fonctionne plutôt bien, mais ça commence a être lourd maintenant de j'étend ce schéma au delà de la ville de Cognac (2) Les multipolygons sont là pour faire du multipolygon... et pas le fleuve lui même. Donc il faut l'utiliser pour les îles. Mais tu peux faire plusieurs multipolygon pour le même fleuve. En effet, je comprend. Je viens de regarder comment était fait la Gironde (autour de Bordeaux) et je m'aperçois qu'il y a en effet plusieurs way fermés pour constituer les rives du fleuve. Ca resoud mon soucis de voir le way grandir-grandir... Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des rivernak qui coupe le fleuve en deux, ça me fait penser a tagger pour le rendu Ensuite tu peux rassembler les différents éléments du fleuve dans un autre relation de type=waterway http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau OK, j'avais pas vu (le wiki est riche mais l'organisation est assez anarchique, on trouve pas toujours facilement les choses). Merci. Donc : les rives en way (name=La Charente, waterway=water_bank et natural=water) Non, il ne faut pas de natural=water, pour un fleuve c'est du waterway=riverbank OK -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Un autre avis ;-) Le dimanche 06 juin 2010 12:27:12, Pierre-Alain Dorange a écrit : Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des rivernak qui coupe le fleuve en deux, ça me fait penser a tagger pour le rendu C'est un bon résumé, c'est (était?) une solution pour contourner le problème des rendus classiques qui ne géraient pas bien les relations multipolygone. Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est l'habitude. Lobying contre : * Les zones d'interconnexion entre plusieurs multipolygone sont tout à fait arbitraire et ne correspondent à rien de réél * S'il me prend de vouloir représenter les bords du fleuve en bleu foncé, c'est très galère car je vais introduire des coupures le long du lit de la rivière aux endroits qui font le collage * Le nom de la rivière doit être indiqué sur chaqu'un des morceaux qui la compose * Si je veux obtenir dans un format vectoriel la forme complète de la rivière, je suis obligé de récupérer à la main, tous les morceaux, faire des découpes et re-collage je ne suis pas seul à penser ça : http://lists.openstreetmap.org/pipermail/talk/2008-February/023009.html Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout cas) des multipolygones : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers Ensuite tu peux rassembler les différents éléments du fleuve dans un autre relation de type=waterway Le problème, c'est que le tout ne forme pas un multipolygon valide au sens OSM du terme (ni au sens GIS du terme d'ailleurs) -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] géoréférencer un cadastre
Bonjour, Je suis incapable de géoréférencé une commune voisine : Le Sap dans l'Orne (61). Il s'agit d'un plan image et la feuille AB contient les croisillons ad-hoc mais les cotes sont du genre 1xxx pour le nord et 45xx pour l'est. Dans la foulée j'ai tenté une autre commune avec des coordonnées à six chiffres, et j'ai réussi le géoréférencement en toute précision sans aucun problème. J'insiste sur les coordonnées parce que j'y vois la cause de mon échec ?? Une idée ? Maurice Boucher ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] géoréférencer un cadastre
Bonjour, maur...@mboucher.info a écrit : Bonjour, Je suis incapable de géoréférencé une commune voisine : Le Sap dans l'Orne (61). Il s'agit d'un plan image et la feuille AB contient les croisillons ad-hoc mais les cotes sont du genre 1xxx pour le nord et 45xx pour l'est. Dans la foulée j'ai tenté une autre commune avec des coordonnées à six chiffres, et j'ai réussi le géoréférencement en toute précision sans aucun problème. J'insiste sur les coordonnées parce que j'y vois la cause de mon échec ?? Une idée ? En effet, en supposant que la commune est en zone Lambert I, il manque quelques chiffres à ces coordonnées. La récupération des coordonnées projetées du repère géodésique de la base du clocher (node_id : 670188590) te donnent une idée des coordonnées qu'il faudrait retrouver : X : 453615 Y : 134625 L'église est sur la planche AB, approximativement en X:5000 et Y:1000 dans le système de la planche AB. Tu peux donc essayer de géoréférencer la planche en ajoutant aux chiffres des croisillons autour de 448615 en X, et 133625 en Y, dans un premier temps. Ta planche sera orientée au Nord et à la bonne échelle. Ensuite, à l'aide de l'outil d'ajustement de la position du calque dans JOSM (3e outil sous la loupe, panneau de gauche), tu peux ajuster la position de la planche en fonction de tes tracés et des repères géodésiques. Bon courage, et merci aux repères géodésiques :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Salut Pierre-Alain, Je me rends compte suite à ta remarque que j'ai pu faire du sale boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites pas à corriger ce que j'ai fait ou à me demander de corriger ces zones si il y a un souci (je ne travaille pas sur ces communes en ce moment). Concernant le cours d'eau (waterway=river) qui devrait si j'ai bien compris correspondre au trajet principal de la Charente, j'ai repéré des trucs assez étranges au niveau de Bassac. N'ayant que le cadastre et des photos pour source d'information, je n'ai pas corrigé, mais si tu connais le trajet principal on pourrait corriger cela aussi par la même occasion. Sur un sujet légèrement différent, j'ai commencé à répertorier les avancées des travaux dans les régions voisines de Cognac sur le wiki (principalement les cantons/communes que j'ai mappé). Tu peux y rajouter bien volontiers tes contributions pour que l'on ait un tableau le plus à jour possible (juste pour information je suis en train de fabriquer un template pour faciliter l'enregistrement de ces informations mais cela va prendre encore un peu de temps). Bon courage, Clément Pierre-Alain Dorange wrote: Bonjour, Mappant autour de Cognac, je retravaille actuellement le fleuve Charente dans ce coin. En effet le fleuve Charente est actuellement composé de petits polygones issus d'un import 'PGS (?) non contiguë (voir exemple (1)) J'ai donc commencé a reconstruire correctement le fleuve à Cognac en traçant le centre du fleuve avec un way (waterway=river) et en transformant les petits polygones isolés en riverbank en traçant les rives du fleuve avec un polygone fermé et en mettant les îles, le tout dans une relation multipolygone. Ca fonctionne plutôt bien, mais ça commence a être lourd maintenant de j'étend ce schéma au delà de la ville de Cognac (2) Donc : les rives en way (name=La Charente, waterway=water_bank et natural=water) les iles en way (place=island) le tout regroupé en relation type=multipolygon et les rives en outer, les iles en inner. Mon soucis est donc que maintenant le multipolygon commence a devenir grand et que si je continu ce schéma pour tout le fleuve je sais pas trop comment ça va se passer avec JOSM... Un autre soucis, c'est que le nom des îles à Cognac est rendu sur le pourtour, c'est étrange et pas très lisible (2). (1) http://www.openstreetmap.org/?lat=45.6396853923798lon=-0.0683856010437012zoom=15 http://www.openstreetmap.org/?lat=45.6396853923798lon=-0.0683856010437012zoom=15 (2) http://www.openstreetmap.org/?lat=45.70458lon=-0.31494zoom=15layers=B000FTF http://www.openstreetmap.org/?lat=45.70458lon=-0.31494zoom=15layers=B000FTF -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ 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] Dessiner un fleuve (grand multipolygon)
2010/6/6 Pierre-Alain Dorange pdora...@mac.com Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des rivernak qui coupe le fleuve en deux, ça me fait penser a tagger pour le rendu Heureusement que les fleuves sont découpés en morceaux (ainsi que les autoroutes ou les lignes de chemins de fers) sinon on se retrouverait avec d'énormes relations comme Sly les aime puisqu'il a fait la proposition de les supprimer pour les limites administratives de la France... ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 6 juin 10 à 17:19, Pieren a écrit : Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des rivernak qui coupe le fleuve en deux, ça me fait penser a tagger pour le rendu Heureusement que les fleuves sont découpés en morceaux (ainsi que les autoroutes ou les lignes de chemins de fers) sinon on se retrouverait avec d'énormes relations comme Sly les aime puisqu'il a fait la proposition de les supprimer pour les limites administratives de la France... ;-) Je comprend et ça semble en effet la bonne manière de faire... Toutefois j'aimerai une solution plus logique que ce charcutage, mais en attendant d'autres possibilités... -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 6 juin 10 à 16:05, Clement Menier a écrit : Salut Pierre-Alain, Salut, Je me rends compte suite à ta remarque que j'ai pu faire du sale boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites pas à corriger ce que j'ai fait ou à me demander de corriger ces zones si il y a un souci (je ne travaille pas sur ces communes en ce moment). Pour l'instant j'ai juste fait le raccord avec ton boulot sur le fleuve à Jarnac. J'ai remarqué 2/3 trucs bizarre mais j'ai pas encore regardé en détail... Concernant le cours d'eau (waterway=river) qui devrait si j'ai bien compris correspondre au trajet principal de la Charente, j'ai repéré des trucs assez étranges au niveau de Bassac. N'ayant que le cadastre et des photos pour source d'information, je n'ai pas corrigé, mais si tu connais le trajet principal on pourrait corriger cela aussi par la même occasion. Je ne connais pas le cours principal du coté de Bassac et ça doit être très compliqué vu comment c'est sur le terrain... Je m'y baigne de temps en temps, c'est tout. Je compte dessiner la fleuve à moyen terme mais il me faudra des infos de terrains en plus, si tu en as je suis preneur évidemment. Mon beau père connais bien le coin (Cognac-Saint-Simon), il y a fait pas mal de plongées archéologiques et à des cartes et une mémoire qui pourrait être utile. Sur un sujet légèrement différent, j'ai commencé à répertorier les avancées des travaux dans les régions voisines de Cognac sur le wiki (principalement les cantons/communes que j'ai mappé). Bonne idée, je compléterai pour ma partie. Tu peux y rajouter bien volontiers tes contributions pour que l'on ait un tableau le plus à jour possible Bien sur. (juste pour information je suis en train de fabriquer un template pour faciliter l'enregistrement de ces informations mais cela va prendre encore un peu de temps). OK -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 6 juin 10 à 12:44, sylvain letuffe a écrit : Un autre avis ;-) C'est une liste de discussion ;-) Le dimanche 06 juin 2010 12:27:12, Pierre-Alain Dorange a écrit : Par contre intellectuellement ça m'apparaît peu satisfaisant de voir des rivernak qui coupe le fleuve en deux, ça me fait penser a tagger pour le rendu C'est un bon résumé, c'est (était?) une solution pour contourner le problème des rendus classiques qui ne géraient pas bien les relations multipolygone. Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est l'habitude. Lobying contre : Je suis en phase avec l'argumentaire. Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout cas) des multipolygones : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers Je comprend pas la technique... un exemple ? -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 17:53:48, Pierre-Alain Dorange a écrit : Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout cas) des multipolygones : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers Je comprend pas la technique... un exemple ? Tu peux pas mieux tomber, ton message m'a rappelé que je n'avais pas avancé depuis quelques temps le tracé de l'Isère (savoie) et j'ai pas mal avancé et collé des morceaux La méthode que j'utilise est décrite ici (avant qu'on me taxe de baratineur ;-), je précise que c'est moi qui est écrit cette documentation il y a pas plus tard qu'après ton 1er mail) : http://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank Le résultat appliqué à l'Isère donne ça : http://www.openstreetmap.org/browse/relation/278498 On peut dès lors la visualiser facilement, et d'un seul tenant avec l'outil magnifique qu'on ne site plus : http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=278498 Et profiter ensuite de la ribambelle d'outils qui peuvent convertir ça dans tous les sens, contrairement, bien sûr à la méthode traditionnelle (j'en fais trop ?) par là : (export de L'isère au format GPX) http://betaplace.emaitie.de/webapps.relation- analyzer/downloadServlet/gpx/278498 La doc générale des multipolygon est là : http://wiki.openstreetmap.org/wiki/Relation:multipolygon Certes, ça demande un peu de s'y plonger, et je pense que c'est pour ça qu'elle est considérée comme hardue ou complexe, mais sitôt qu'il faudra mettre une île, il faudra de toute façon l'utiliser, alors ! En plus JOSM commence vraiment bien gérer les relations en indiquant les îles (role=inner) si il n'y a pas de trous, etc. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 17:53:48, Pierre-Alain Dorange a écrit : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers Je comprend pas la technique... un exemple ? Honte sur moi, j'ai copié ce lien sur la base uniquement de l'image mais je n'avais pas vu la description complètement tirée par les cheveux et obsolète. Mon explication est donc bien là : http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 6 juin 10 à 16:05, Clement Menier a écrit : Je me rends compte suite à ta remarque que j'ai pu faire du sale boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites pas à corriger ce que j'ai fait ou à me demander de corriger ces zones si il y a un souci (je ne travaille pas sur ces communes en ce moment). En fait tu n'avais pas tagger les iles, j'ai fait un peu de ménage en création un multipolygone sur Jarnac pour pouvoir y intégrer les îles (place=island en member=inner) et j'ai ajouter les écluses. Pas encore totalement finit. -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu train et ferry
Guillaume Allegre a écrit : Le Fri 04 Jun 2010 à 15:08 +0200, Rodolphe Quiedeville a ecrit : http://tile.quiedeville.org/train/?zoom=10lat=6159703.94077lon=-425964.22107layers=B000 Ceci étant fait il faut encore que j'améliore mes rendus, et aussi réfléchir à un algo pour trouver les portions de voies isolées. Pas mal du tout. 1) Quelles unités tu utilises pour tes coordonnées ? Est-ce qu'une version en vraies lat/lon est prévue ? Je suis un grand utilisateur du Mapjumper, et là ça passe pas ! Corrigé, j'avais laissé le Permalink par défaut en 900913, c'est modifié, Mapjumper devrait apprécier. 2) Pourrais-tu ajouter les highway=preserved ? Peut-être dans une autre couleur ? Par exemple celui-ci (petit train de la Mure, Isère) : http://www.openstreetmap.org/?mlat=44.9687mlon=5.6907zoom=14layers=B000FTF Je vais regarder cela. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu train et ferry
Le Sun 06 Jun 2010 à 21:33 +0200, Rodolphe Quiedeville a ecrit : 1) Quelles unités tu utilises pour tes coordonnées ? Est-ce qu'une version en vraies lat/lon est prévue ? Je suis un grand utilisateur du Mapjumper, et là ça passe pas ! Corrigé, j'avais laissé le Permalink par défaut en 900913, c'est modifié, Mapjumper devrait apprécier. merci ! -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 06/06/2010 12:44, sylvain letuffe a écrit : Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est l'habitude. Pas seulement, voir plus loin Lobying contre : * Les zones d'interconnexion entre plusieurs multipolygone sont tout à fait arbitraire et ne correspondent à rien de réél * S'il me prend de vouloir représenter les bords du fleuve en bleu foncé, c'est très galère car je vais introduire des coupures le long du lit de la rivière aux endroits qui font le collage * Le nom de la rivière doit être indiqué sur chaqu'un des morceaux qui la compose * Si je veux obtenir dans un format vectoriel la forme complète de la rivière, je suis obligé de récupérer à la main, tous les morceaux, faire des découpes et re-collage je ne suis pas seul à penser ça : http://lists.openstreetmap.org/pipermail/talk/2008-February/023009.html Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout cas) des multipolygones : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers Le problème, c'est que le tout ne forme pas un multipolygon valide au sens OSM du terme (ni au sens GIS du terme d'ailleurs) Sly, tu as raison, en partie : le tag riverbank pour cartographier des plans d'eau tel qu'utilisés couramment n'est pas exact. Le tag devrai être une traduction anglaise de plan d'eau sur rivière. Le rendu mapnik est celui d'un area alors que riverbank désigne un way. L'usage du multipolygone semblerait plus exact, comme pour les boundary Seulement... Un multypolygone riverbank n'est jamais fermé : il y a des confluents. Et au confluent, la limite du fleuve ou de la rivière n'est plus un riverbank. Pour fermer le multipolygone, je devrais mettre un way dans le confluent du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau. (Déjà que, à Lyon, il y a quelque chose de spécifique au milieu du Rhône et de la Saône au dessus de l'eau (de l'o) : un accent circonflexe) Tout ça pour dire que la solution du multipolygone n'est pas complètement satisfaisante non plus, ni formellement, ni pour le rendu. Donc la solution adoptée, pragmatique, est de sectionner le fleuve et d'utiliser le riverbank comme un area, ce qui le rend plus maitrisable sur des longues distance, de le rendre moins fragile aux erreurs (la moindre erreur fout en l'air l'ensemble du multipolygone). Pas satisfaisant, mais plus maniable. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 22:03:51, Vincent Pottier a écrit : Sly, tu as raison, en partie : le tag riverbank pour cartographier des plans d'eau tel qu'utilisés couramment n'est pas exact. Le tag devrai être une traduction anglaise de plan d'eau sur rivière. Le rendu mapnik est celui d'un area alors que riverbank désigne un way. ça, à la limite, le nom, je m'en fiche un peu, tant pis pour la confusion, du moment que c'est expliqué et la page sur riverbank l'explique bien. Seulement... Un multypolygone riverbank n'est jamais fermé : il y a des confluents. Et au confluent, la limite du fleuve ou de la rivière n'est plus un riverbank. Tu marques un point. Mais qui confirme le choix médiocre du nom, les deux cas présente la même confusion d'avoir le mot riverbank (qui suggère donc une ligne) alors que nous taggons une surface. Mon cas pourrait s'en sortir s'il décidait d'appler un chat un chat, c'est à dire une rivière Genre : type=multipolygon + waterway=river (encore qu'on pourrait discuter du way du mot waterway) Pour fermer le multipolygone, je devrais mettre un way dans le confluent du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau. Pas nécessairement, car tu ne tagguerais justement pas ce way en riverbank, mais simplement en rien du tout (Déjà que, à Lyon, il y a quelque chose de spécifique au milieu du Rhône et de la Saône au dessus de l'eau (de l'o) : un accent circonflexe) ? Donc la solution adoptée, pragmatique, est de sectionner le fleuve et d'utiliser le riverbank comme un area, ce qui le rend plus maitrisable sur des longues distance, Maitrisable dans quel sens ? de le rendre moins fragile aux erreurs (la moindre erreur fout en l'air l'ensemble du multipolygone). J'ai envie de sortir une boutade : Le défaut du gros multipolygon est qu'une erreur fout tout en l'air, et l'avantage du gros multipolygon est que ça fout tout en l'air. Dans le sens où un trou sur le parcours est (visuellement en tout cas) rapidement visible, donc on sait qu'il y a une erreur. Dans le cas de multiples bouts, un petit morceau peut manquer et ça se voit moins. Après, si on a une logique rendu c'est clair, c'est con, la rivière a disparu. Maintenant si je suis conducteur de péniche et que je veux faire lyon-valence, c'est quand même con que mon GPS m'indique de passer par le canal du rhin pour revenir par la méditéranée -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Pierre-Alain Dorange wrote: Le 6 juin 10 à 16:05, Clement Menier a écrit : Je me rends compte suite à ta remarque que j'ai pu faire du sale boulot au niveau de Jarnac/Gondeville/Triac-Lautrait/Bassac. N'hésites pas à corriger ce que j'ai fait ou à me demander de corriger ces zones si il y a un souci (je ne travaille pas sur ces communes en ce moment). En fait tu n'avais pas tagger les iles, j'ai fait un peu de ménage en création un multipolygone sur Jarnac pour pouvoir y intégrer les îles (place=island en member=inner) et j'ai ajouter les écluses. Pas encore totalement finit. Merci pour tes corrections. En effet je ne maîtrise pas encore les multipolygones, mais maintenant que j'ai un exemple j'essaierai de le suivre si je rencontre ce type de construction. Merci aussi pour avoir updater tes contributions dans le wiki. Clément. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 06/06/2010 22:27, sylvain letuffe a écrit : Mon cas pourrait s'en sortir s'il décidait d'appler un chat un chat, c'est à dire une rivière Genre : type=multipolygon + waterway=river (encore qu'on pourrait discuter du way du mot waterway) L'intérêt de distinguer l'area (et les multipolygones) du way, et de reconstruire le tout dans un type=river, c'est qu'une rivière est un plan d'eau ET un cours d'eau, voire des écluses, des barrages, une activité économique et autres Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en désigner la géométrie. Le multipolygone n'est donc pas river mais pourrait être river_surface. En ce moment, sur la ML anglaise, il y a une discussion pour tagger les escaliers extra-larges. Comment cartographier une objet qui est à la fois une surface et un axe ? C'est la question des rivières : la relation river avec des éléments de surface et des éléments axiaux est une solution relativement propre. Difficilement applicable à la voirie vue le nombre de routes. Quoique, j'espère que dans quelques temps, les way:highway + relation:associated_street (adressage) + area:... seront regroupés dans une relation street (pourquoi avoir affublé la relation d'un associated_quelquechose ? C'est, il me semble, de la courte vue) Pour fermer le multipolygone, je devrais mettre un way dans le confluent du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau. Pas nécessairement, car tu ne tagguerais justement pas ce way en riverbank, mais simplement en rien du tout On n'est pas très habitué à mettre le tag river... dans la relation, mais sur le(s) way(s) outer. Bon je suis d'accord que la pratique pourrait changer ! Donc la solution adoptée, pragmatique, est de sectionner le fleuve et d'utiliser le riverbank comme un area, ce qui le rend plus maitrisable sur des longues distance, Maitrisable dans quel sens ? Longueur du cours d'eau. Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée. Si je dois m'assurer de la cohésion des 1000 km de la Loire... Il y a des problèmes pour la coastline, on retrouverait ce type de problème (à moindre échèle) pour les cours d'eau. J'ai envie de sortir une boutade : Le défaut du gros multipolygon est qu'une erreur fout tout en l'air, et l'avantage du gros multipolygon est que ça fout tout en l'air. Dans le sens où un trou sur le parcours est (visuellement en tout cas) rapidement visible, donc on sait qu'il y a une erreur. Dans le cas de multiples bouts, un petit morceau peut manquer et ça se voit moins. Après, si on a une logique rendu c'est clair, c'est con, la rivière a disparu. Maintenant si je suis conducteur de péniche et que je veux faire lyon-valence, c'est quand même con que mon GPS m'indique de passer par le canal du rhin pour revenir par la méditérané Le logiciel de routage ne se basera pas sur les multipolygones, les plans d'eau, mais sur du filaire (le waterway) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit : L'intérêt de distinguer l'area (et les multipolygones) du way, et de reconstruire le tout dans un type=river, c'est qu'une rivière est un plan d'eau ET un cours d'eau, voire des écluses, des barrages, une activité économique et autres Tout à fait. Et ces éléments peuvent être mis en relation, pourquoi pas. Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en désigner la géométrie. Le multipolygone n'est donc pas river mais pourrait être river_surface. C'est vrai, mon exemple n'étais pas très bon, un river_surface serait un mot mieux choisi puisque c'est ça que ça représente. relation river avec des éléments de surface et des éléments axiaux est une solution relativement propre. Oui, ce que je trouve moyennement bien fichu c'est uniquement la partie description de la surface. Je ne vois pas d'inconvénients à créer une autre relation type=river qui contient la relation qui décrit la surface, le way (ou relation) qui décrit l'axe, et tout ce qu'on voudra bien y mettre (j'ai malgré tout un peu de mal à imaginer l'usage, mais ma foi, certain y trouverons bien un intérêt) Ce que je vois bien par contre, c'est qu'aujourd'hui le modèle de donnée ne me permet pas de construire par exemple une carte des cours d'eau français de longueur supérieur à X km cf l'horreur à laquelle je me suis arrété : http://wiki.openstreetmap.org/wiki/File:Hydro.png Maitrisable dans quel sens ? Longueur du cours d'eau. Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée. Si je dois m'assurer de la cohésion des 1000 km de la Loire... Il y a des problèmes pour la coastline, on retrouverait ce type de problème (à moindre échèle) pour les cours d'eau. Avec la solution du multipoly qui couvre tout le cours d'eau, une modification locale sur un poly valide n'a aucune raison d'entrainer une rupture 100km plus loin, vu que justement on n'a téléchargé que les riverbank d'une petite zone. En revanche, et c'est là que je trouve que c'est pernitieux les multiples bouts autonomes de surface qui forment une plus grosse surface, c'est que si je calcul la longeur/surface d'un fleuve, une valeur me sera retournée, mais qui sera fausse Le logiciel de routage ne se basera pas sur les multipolygones, les plans d'eau, mais sur du filaire (le waterway) Certes, le principe est similaire, si mon waterway à un trou, graphiquement ça ne se voit que mal mais le routage est interompu. Certes encore, il existe de toute façon des outils pour contrôler plus ou moins tout. Je reviens un peu sur ton example du coastline, ça me donne des idées :-) La solution utilisée est une re-construction périodique des côtes pour qu'un controle semi-humain valide que tout est bien fermé avant de lancer des rendus/utilisations. Une bonne (peut-être ?) idée serait de faire du controle d'integrité et du versionning. Si la relation X qui représente un polygone ne forme plus un polygone, on ne fait pas la mise à jour. C'est ce que je fais en fait sans y avoir pensé ici : http://beta.letuffe.org/ressources/export-communes/ Je ne rend disponible une mise à jour que si celle-ci est complète est valide, sinon je fourni la précédente -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dessiner un fleuve (grand multipolygon)
Le 06/06/2010 23:20, sylvain letuffe a écrit : Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit : Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en désigner la géométrie. Le multipolygone n'est donc pas river mais pourrait être river_surface. C'est vrai, mon exemple n'étais pas très bon, un river_surface serait un mot mieux choisi puisque c'est ça que ça représente. relation river avec des éléments de surface et des éléments axiaux est une solution relativement propre. Oui, ce que je trouve moyennement bien fichu c'est uniquement la partie description de la surface. Je ne vois pas d'inconvénients à créer une autre relation type=river qui contient la relation qui décrit la surface, le way (ou relation) qui décrit l'axe, et tout ce qu'on voudra bien y mettre (j'ai malgré tout un peu de mal à imaginer l'usage, mais ma foi, certain y trouverons bien un intérêt) Ce que je vois bien par contre, c'est qu'aujourd'hui le modèle de donnée ne me permet pas de construire par exemple une carte des cours d'eau français de longueur supérieur à X km cf l'horreur à laquelle je me suis arrété : http://wiki.openstreetmap.org/wiki/File:Hydro.png Maitrisable dans quel sens ? Longueur du cours d'eau. Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée. Si je dois m'assurer de la cohésion des 1000 km de la Loire... Il y a des problèmes pour la coastline, on retrouverait ce type de problème (à moindre échèle) pour les cours d'eau. Avec la solution du multipoly qui couvre tout le cours d'eau, une modification locale sur un poly valide n'a aucune raison d'entrainer une rupture 100km plus loin, vu que justement on n'a téléchargé que les riverbank d'une petite zone. La solution est mieux, théoriquement. Mais avec des segments, les crottes chez mon voisins n'entachent pas mon bac-à-sable. C'est plus petit mais plus sur. Et puis, je me sens le courage de cartographier 80 km du cours d'eau, pas 800 km. Dois-je attendre que le courage me vienne ? La cohésion locale, je la contrôle dans JOSM, donc en direct, pas dans osmose, en différé. Quand j'édite des bouts de multipolygones dans JOSM, j'ai des formes bizarres, pas belles, pas finies. Bref, ta solution est mieux, théoriquement, ou à terme. Mais les segments, c'est plus politiquement correct, plus sur, à court terme, plus rassurant. En revanche, et c'est là que je trouve que c'est pernitieux les multiples bouts autonomes de surface qui forment une plus grosse surface, c'est que si je calcul la longeur/surface d'un fleuve, une valeur me sera retournée, mais qui sera fausse Pas à partir de ça : somme des role=waterbank De toute façon on ne calculera que la surface 'cartographiée' du fleuve. Le logiciel de routage ne se basera pas sur les multipolygones, les plans d'eau, mais sur du filaire (le waterway) Certes, le principe est similaire, si mon waterway à un trou, graphiquement ça ne se voit que mal voire pas du tout sous un waterbank mais le routage est interompu. On a le même problème que pour les routes... On pourrait reprendre l'algorythme des bouts de train (voir un autre mail) et repérer les waterways cul-de-sac, qui ne sont pas la mer. Je pense qu'il y a un tag pour les pertes pour éviter les faux positifs. Certes encore, il existe de toute façon des outils pour contrôler plus ou moins tout. Pas encore mais ça vient ! Je reviens un peu sur ton example du coastline, ça me donne des idées :-) La solution utilisée est une re-construction périodique des côtes pour qu'un controle semi-humain valide que tout est bien fermé avant de lancer des rendus/utilisations. Une bonne (peut-être ?) idée serait de faire du controle d'integrité et du versionning. Si la relation X qui représente un polygone ne forme plus un polygone, on ne fait pas la mise à jour. C'est ce que je fais en fait sans y avoir pensé ici : http://beta.letuffe.org/ressources/export-communes/ Je ne rend disponible une mise à jour que si celle-ci est complète est valide, sinon je fourni la précédente Ouais, il est possible que des serveurs label qualité vont se multiplier, notamment pour les collectivités, où la donnée n'est pas de toute première fraicheur, mais relue et filtrée. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] 記事の執筆
On Sun, Jun 06, 2010 at 01:51:20PM +0900, Hiroshi Miura wrote: 平壌とかの図を外してスペースを捻出しました。 Wikipediaの話しはいれませんでした。 JAXAの件を反映し、リファレンスを入れました。 billinの話しをいれました。 ハイチとチリの事実を反映しました。 4ページでみっちり入れれば、6000字です。各ページに１つづつ図表のため、 ４０００字という ところですから、調整の範囲内かもしれません。 大筋でよいと思います。後は、レイアウトしてもらって、はみ出るかを見てもらう、 はみ出るようならば微調整ですね。 まだ気になっているのは、 地図キャプチャは、ロンドンでいいだろうか。実は、東京のほうがいい？ 日本全体のほうがいいかもしれない？ 図1で、倫敦と書いてあるので、ここはやはり倫敦でしょう。 タイトルは、まだしっくりこないかなぁ。 確かに。思案のしどころですね。 あと、 分断されたデータが集約されることによる効果 オープンデータ とタイトルが二段になっていますが、「オープンデータ」のほうは 不要だと思います。 oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 記事の執筆
三浦です。 みなさま、ありがとうございました。 http://osm.jp/node/1406 に、最終稿をアップロードしました。 素人にわかるよう、冒頭はさらに見直しました。 タイトルは、 自由な地図によるオープンデータ・イノベーション：OpenStreetMap としてみました。 グラフは、今回あらたに起こしました。 世界と日本の活動メンバー数を一緒にのせると、日本のメンバーの あまりの桁違いに悲しくなります。 ぜひ、万のオーダーになるといいですねぇ。 三浦 -- Ovi Mail: Get mail on your mobile or the web http://mail.ovi.com ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 記事の執筆
On Mon, Jun 07, 2010 at 12:11:24AM +0900, Hiroshi Miura wrote: みなさま、ありがとうございました。 http://osm.jp/node/1406 に、最終稿をアップロードしました。 更に良くなりました。 GO! oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] UK Project of the week - trace a village off of OSSV?
Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some of the arguments most likely going to be brought up against this sort of non local tracing: 1) OS data might have mistakes, be outdated and generally not as good as what OSM aims for: Yes, no doubt OS has errors and can be outdated in many places by a couple of years ( I have found more than enough of those myself). Furthermore, all of the OS products released lack many of the properties we are interested in like one way roads, turn and other restrictions, POIs, foot and cycle ways and all the other things that make OSM data such a rich and valuable dataset. So yes, the OS data will clearly not replace any of the traditional OSM surveying techniques or be the end of things. But it can be a great basis to build upon. As a comparison, have a look (assuming you have a timecapsal ;-)) at what the data of e.g. central London looked like in 2007. It already had surprisingly many roads, but hardly any POIs or other properties that we aim for now. Most of that came later in many iterations of improvement. A single pass of OSM surveying is not any better than the OS data per se. Also given that the errors introduced by tracing OS data are exactly the same type of errors introduced by manual OSM surveying, i.e. misspellings in roads, missing roads, outdated roads, ... We need to have the tools to deal with this kind of maintenance anyway. It is the iterations that make OSM data what it is, not the first pass ground survey. Creating a blanket base layer from OS data allows us to much better focus on the aspects that do distinguish us from every other map data provider with having to waste as little as possible resources on the stuff everyone else has too. 2) large scale imports and tracing hinders community growth: This perhaps is the more important of the two arguments, as indeed what distinguishes us from everyone else is the community and without the community and its constant iterations and improvements, OSM data will bit rot just as much as all other data. However I don't think there is any clear evidence either way of what non local mapping does to communities and it remains hotly debated. The negative effects claimed are usually of the form a) The area looks complete, there is nothing more to do, so why bother. Or, it isn't as much fun to add a POI than a whole new village on a blank canvas. b) I put in all this effort into mapping an area and along comes an import and steam rollers all this into a mess, I am leaving. c) imports introduce a new class of bugs, e.g. duplicate nodes or broken connectivity that OSM mappers wouldn't so we don't have the tools to deal with these sort of errors correctly. b) and c) are specific to imports and thus manual tracing shouldn't suffer the same issues. a) may be the case, but it is clearly a case that we need to be able to deal with anyway, as more and more areas become complete by them selves. And looking at the better mapped areas, like Germany or some of the UK cities, I don't think there is any evidence that you can't attract new comers into already mapped areas. It is potentially also offset by all those people who simple want to use the data for something like embed a map into their blog or use OSM data on their Garmin, their phone, their game, their ... and will fix the odd bug they discover while doing so, but can't really as it simply isn't complete enough yet. Other examples of remote mapping have also been fairly successful. The most obvious one was Haiti. It's initial phase was entirely arm chair mapping and had no
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
Kai, I think this is a good idea, and a very well presented argument - a push to get UK OSM coverage up would make the uk dataset more useful (more chance of being able to search for an address etc.). I think it would be worth treating a 'blind' tracing (as opposed to tracing an area that you know, but have not surveyed) a bit like an import and adding a 'verified=no' tag. Then when someone on the ground visits the area they can update the 'verified' tag - we could even create a map overlay to highlight the unverified areas to encourage 'on the ground' surveys to add the extra detail that makes OSM maps more interesting than others. Regards Graham. On 6 June 2010 12:07, Kai Krueger kakrue...@gmail.com wrote: Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some of the arguments most likely going to be brought up against this sort of non local tracing: 1) OS data might have mistakes, be outdated and generally not as good as what OSM aims for: Yes, no doubt OS has errors and can be outdated in many places by a couple of years ( I have found more than enough of those myself). Furthermore, all of the OS products released lack many of the properties we are interested in like one way roads, turn and other restrictions, POIs, foot and cycle ways and all the other things that make OSM data such a rich and valuable dataset. So yes, the OS data will clearly not replace any of the traditional OSM surveying techniques or be the end of things. But it can be a great basis to build upon. As a comparison, have a look (assuming you have a timecapsal ;-)) at what the data of e.g. central London looked like in 2007. It already had surprisingly many roads, but hardly any POIs or other properties that we aim for now. Most of that came later in many iterations of improvement. A single pass of OSM surveying is not any better than the OS data per se. Also given that the errors introduced by tracing OS data are exactly the same type of errors introduced by manual OSM surveying, i.e. misspellings in roads, missing roads, outdated roads, ... We need to have the tools to deal with this kind of maintenance anyway. It is the iterations that make OSM data what it is, not the first pass ground survey. Creating a blanket base layer from OS data allows us to much better focus on the aspects that do distinguish us from every other map data provider with having to waste as little as possible resources on the stuff everyone else has too. 2) large scale imports and tracing hinders community growth: This perhaps is the more important of the two arguments, as indeed what distinguishes us from everyone else is the community and without the community and its constant iterations and improvements, OSM data will bit rot just as much as all other data. However I don't think there is any clear evidence either way of what non local mapping does to communities and it remains hotly debated. The negative effects claimed are usually of the form a) The area looks complete, there is nothing more to do, so why bother. Or, it isn't as much fun to add a POI than a whole new village on a blank canvas. b) I put in all this effort into mapping an area and along comes an import and steam rollers all this into a mess, I am leaving. c) imports introduce a new class of bugs, e.g. duplicate nodes or broken connectivity that OSM mappers wouldn't so we don't have the tools to deal with these sort of errors correctly. b) and c) are specific to imports and thus manual tracing shouldn't suffer the same issues. a) may be the case, but it is clearly a case that we need to be
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
If you are tracing from StreetView please, please, please properly source your ways: source=OS_OpenData_StreetView http://wiki.openstreetmap.org/wiki/Ordnance_Survey_Opendata#Attributing_OS Tim --- On Sun, 6/6/10, Kai Krueger kakrue...@gmail.com wrote: From: Kai Krueger kakrue...@gmail.com Subject: [Talk-GB] UK Project of the week - trace a village off of OSSV? To: 'talk-gb' talk-gb@openstreetmap.org Date: Sunday, 6 June, 2010, 12:07 Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some of the arguments most likely going to be brought up against this sort of non local tracing: 1) OS data might have mistakes, be outdated and generally not as good as what OSM aims for: Yes, no doubt OS has errors and can be outdated in many places by a couple of years ( I have found more than enough of those myself). Furthermore, all of the OS products released lack many of the properties we are interested in like one way roads, turn and other restrictions, POIs, foot and cycle ways and all the other things that make OSM data such a rich and valuable dataset. So yes, the OS data will clearly not replace any of the traditional OSM surveying techniques or be the end of things. But it can be a great basis to build upon. As a comparison, have a look (assuming you have a timecapsal ;-)) at what the data of e.g. central London looked like in 2007. It already had surprisingly many roads, but hardly any POIs or other properties that we aim for now. Most of that came later in many iterations of improvement. A single pass of OSM surveying is not any better than the OS data per se. Also given that the errors introduced by tracing OS data are exactly the same type of errors introduced by manual OSM surveying, i.e. misspellings in roads, missing roads, outdated roads, ... We need to have the tools to deal with this kind of maintenance anyway. It is the iterations that make OSM data what it is, not the first pass ground survey. Creating a blanket base layer from OS data allows us to much better focus on the aspects that do distinguish us from every other map data provider with having to waste as little as possible resources on the stuff everyone else has too. 2) large scale imports and tracing hinders community growth: This perhaps is the more important of the two arguments, as indeed what distinguishes us from everyone else is the community and without the community and its constant iterations and improvements, OSM data will bit rot just as much as all other data. However I don't think there is any clear evidence either way of what non local mapping does to communities and it remains hotly debated. The negative effects claimed are usually of the form a) The area looks complete, there is nothing more to do, so why bother. Or, it isn't as much fun to add a POI than a whole new village on a blank canvas. b) I put in all this effort into mapping an area and along comes an import and steam rollers all this into a mess, I am leaving. c) imports introduce a new class of bugs, e.g. duplicate nodes or broken connectivity that OSM mappers wouldn't so we don't have the tools to deal with these sort of errors correctly. b) and c) are specific to imports and thus manual tracing shouldn't suffer the same issues. a) may be the case, but it is clearly a case that we need to be able to deal with anyway, as more and more areas become complete by them selves. And looking at the better mapped areas, like Germany or some of the UK cities, I don't think there is any evidence that you can't attract new comers into already mapped areas. It is potentially also offset by
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
We've never bothered adding verified=no for tracing from Yahoo maps with Potlatch, or adding new roads in the city with only very rough GPS accuracy, or any of the other sources of OSM data, many of which are often worse in quality than the Ordnance Survey data (which, from all I've seen, is really very good). So we need not worry too much about marking objects as 'unclean' just because they were traced from OS. They are no more likely to need re-surveying than anything else on the map. However, where the OS data is conflicting with data already on the map, of course it makes sense to tag FIXME or similar to solve the puzzle on the ground. -- Ed Avis e...@waniasset.com ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
I've support this 'project of the week' and I've already tested the idea in a small area. If you look around the web for critical views on Openstreetmap it does look like the big chunks of missing streets puts people off. A few opinions to add. 1. If you know how to convert the shapefile, use Vector Map District instead of Streetview. [Link to Converting Guidehttp://wiki.openstreetmap.org/wiki/Using_OS_Shapefiles ] 2. Use the newly created 'Ito _ OS locator layer' to get street names. Do this for areas that appear to have been completely 'street mapped'. [link to using Ito layer http://wiki.openstreetmap.org/wiki/Using_OS_Locator_files] 3. Use the streetview layer as final comparison Jason ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
Kai Krueger wrote: So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. How about concentrating on the stuff that you can't get from a ground survey? Woodland, most waterways, that sort of thing... Also, while the offset in the StreetView data is tiny compared to e.g. NPE, I'd suggest picking areas where it's possible to check the alignment of the background (perhaps from a couple of perpendicular major roads with lots of traces on). ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
I like the idea for a project of the week using OS OpenData StreetView, but would suggest that before we add lots of new roads we work hard to get roads which are already in OSM properly named. Firstly it is improving data which is already there, secondly it using a second, independent, data source. Not a patch on ground survey, but at least it means that editors of the data have to engage with the data sources and their discrepancies. I would not be happy at OSM becoming a largely a subset of Ordnance Survey data without more thought (but also see below). As for the status of noname roads, I have named perhaps 2000 or so in West London and Merseyside in the past few weeks. There are still substantial parts of the South East and North West with many unnamed roads. I have not estimated the number, but its still in the thousands. Unfortunately the noname map layer on the website has not been updated (along with other Cloudmade maps), so I'd suggest using beta.letuffe.org which has a noname overlay (link is to Wigan area). It is important not to forget that a mass import of the VectorMap District roads named from Locator will become possible within the next six months. I'm sure several people are looking at a) how to accurately name the VMD roads from Locator ; and b) how to find only those roads which are not already in OSM (e.g., by using the techniques of the French CORINE project). Once viable technical solutions to these issues are available we will be able to import ALL the missing roads SHOULD we wish to. Manual tracing of StreetView data should be considered in this context. Personally, I don't think mass imports of VectorMap District road data should be contemplated, at least for 6 months or so, for all the usual reasons (Pottery, Imports and the Community). However, availability outwith the planet database of those roads in VectorMap District and not in OSM could be used to enhance downstream applications, such as Garmin extracts, and specific map renders. In other words we should be able to generate GB road-complete products without risking some of the known effects on community building of armchair mapping. I think there is plenty of scope to think of other 'added-value' projects with the StreetView data, these are some off the top of my head: * Getting all schools in to coincide with publication of league tables (its another data source to cross-check) * Mapping all professional football grounds (see for instance Blundell Park) * Ditto for other sports (e.g., crags used for climbing, horse racecourses, ...). * Mapping landuse=residential for areas without streets (shapes can be used as a guide to poorly mapped areas) * Get all churches tagged with man_made=tower or man_made=spire if applicable so that we can do OSGB like renders * Get all bridges tagged and marked for major waterways. Bridges across large rivers are surprisingly poorly mapped. It ought to be possible to identify these and make our existing data better. * Replace larger expanses of water mapped from NPE or Yahoo with OSSV or OS VDM.I hope these thoughts are not too controversial. I must add that I am not a zealot for the no import cause, but I do recognise that there is a reasonable case for it. Regards, Jerry Clough From: Kai Krueger kakrue...@gmail.com To: talk-gb talk-gb@openstreetmap.org Sent: Sun, 6 June, 2010 12:07:33 Subject: [Talk-GB] UK Project of the week - trace a village off of OSSV? Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?
Hi, Kai Krueger wrote: I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Is anybody sure that the OS's attribution requirements are adequately addressed by current practice, and when moving to ODbL later? Under ODbL it will be possible to use non-substantial amounts of data from OSM without any attribution (this is not disputed), and furthermore (this is disputed and the following is only the opinion of myself plus at least one member of the licensing working group) it will be possible to create a produced work from OSM data and license that under a license that does not require attribution, so attribution can become lost down the line. Before anyone starts massively using OS data for anything else than a comparison, I strongly suggest to get a very clear view of this, either by having the OS say yes ok or at least getting a statement from our own licensing working group. Because doing large-scale tracing and later having to remove it all sucks. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?, (Kai Krueger)
At risk of being a fly in the ointment, judging by the largely favourable responses to this idea, I for one would like to register myself as -1. Rant Please don't map an area if you are not familiar with it. I have done some armchair mapping, but only where I am familiar with the area, and feel I can add value to the data I am entering. If you are that desperate for a 'complete' map, go out and do more surveying, or just use OS or other commercially available products. I just feel that blatant, blind copying of OS data is prostituting what I thought Open Street Map was meant to be about./Rant OK, I've got my tin hat on: standing by for incoming... ;-) Phil. talk-gb-requ...@openstreetmap.org wrote: -- Message: 1 Date: Sun, 06 Jun 2010 12:07:33 +0100 From: Kai Krueger kakrue...@gmail.com Subject: [Talk-GB] UK Project of the week - trace a village off of OSSV? To: 'talk-gb' talk-gb@openstreetmap.org Message-ID: 4c0b8175.30...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some of the arguments most likely going to be brought up against this sort of non local tracing: 1) OS data might have mistakes, be outdated and generally not as good as what OSM aims for: Yes, no doubt OS has errors and can be outdated in many places by a couple of years ( I have found more than enough of those myself). Furthermore, all of the OS products released lack many of the properties we are interested in like one way roads, turn and other restrictions, POIs, foot and cycle ways and all the other things that make OSM data such a rich and valuable dataset. So yes, the OS data will clearly not replace any of the traditional OSM surveying techniques or be the end of things. But it can be a great basis to build upon. As a comparison, have a look (assuming you have a timecapsal ;-)) at what the data of e.g. central London looked like in 2007. It already had surprisingly many roads, but hardly any POIs or other properties that we aim for now. Most of that came later in many iterations of improvement. A single pass of OSM surveying is not any better than the OS data per se. Also given that the errors introduced by tracing OS data are exactly the same type of errors introduced by manual OSM surveying, i.e. misspellings in roads, missing roads, outdated roads, ... We need to have the tools to deal with this kind of maintenance anyway. It is the iterations that make OSM data what it is, not the first pass ground survey. Creating a blanket base layer from OS data allows us to much better focus on the aspects that do distinguish us from every other map data provider with having to waste as little as possible resources on the stuff everyone else has too. 2) large scale imports and tracing hinders community growth: This perhaps is the more important of the two arguments, as indeed what distinguishes us from everyone else is the community and without the community and its constant iterations and improvements, OSM data will bit rot just as much as all other data. However I don't think there is any clear evidence either way of what non local mapping does to communities and it remains hotly debated. The negative effects claimed are usually of the form a) The area looks complete, there is nothing more to do, so why bother. Or, it isn't as much fun to add a POI than a whole new village on a blank canvas. b) I put in all this effort into mapping an area
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?, (Kai Krueger)
+1... or -1 as well? not sure how the arithmetic of these is supposed to work. anyway, i agree with phil. cheers, matt On Sun, Jun 6, 2010 at 10:13 PM, Phil James peerja...@googlemail.com wrote: At risk of being a fly in the ointment, judging by the largely favourable responses to this idea, I for one would like to register myself as -1. Rant Please don't map an area if you are not familiar with it. I have done some armchair mapping, but only where I am familiar with the area, and feel I can add value to the data I am entering. If you are that desperate for a 'complete' map, go out and do more surveying, or just use OS or other commercially available products. I just feel that blatant, blind copying of OS data is prostituting what I thought Open Street Map was meant to be about./Rant OK, I've got my tin hat on: standing by for incoming... ;-) Phil. talk-gb-requ...@openstreetmap.org wrote: -- Message: 1 Date: Sun, 06 Jun 2010 12:07:33 +0100 From: Kai Krueger kakrue...@gmail.com Subject: [Talk-GB] UK Project of the week - trace a village off of OSSV? To: 'talk-gb' talk-gb@openstreetmap.org Message-ID: 4c0b8175.30...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello everyone, I would like to suggest as a sort of Project of the week for the UK for people to pick a random town or village somewhere in the UK that so far has poor coverage and trace it's roads from OS OpenData StreetView. Despite the various claims over the years that the UK road will be road complete by the end of the year, the UK is still a far distance off of that target. I have heard the numbers that so far we have on the order of 50% of named roads (people who are working on OS - OSM comparisons please correct me if I am wrong). Which is by no means a small feat of achieving, but also not as high as one would like it to be. So let us try and accelerate this a bit by everyone picking a small random town or village somewhere in the UK and trace the roads from StreetView. It probably only takes about 10 - 20 minutes for a small village and even a small town isn't too bad to do (if the weather is bad and you can't go out). So with the help of OS data, we can get a big step closer to where we would like to be and use it as a basis to continue to improve beyond the quality of OS data or any other commercial map provider. (If you are convinced already, then no need to read the rest of the email) I know that many people are opposed to armchair mapping or imports (and btw I am not proposing a full scale import here, but manual tracing instead) and so I'd like to counter some of the arguments most likely going to be brought up against this sort of non local tracing: 1) OS data might have mistakes, be outdated and generally not as good as what OSM aims for: Yes, no doubt OS has errors and can be outdated in many places by a couple of years ( I have found more than enough of those myself). Furthermore, all of the OS products released lack many of the properties we are interested in like one way roads, turn and other restrictions, POIs, foot and cycle ways and all the other things that make OSM data such a rich and valuable dataset. So yes, the OS data will clearly not replace any of the traditional OSM surveying techniques or be the end of things. But it can be a great basis to build upon. As a comparison, have a look (assuming you have a timecapsal ;-)) at what the data of e.g. central London looked like in 2007. It already had surprisingly many roads, but hardly any POIs or other properties that we aim for now. Most of that came later in many iterations of improvement. A single pass of OSM surveying is not any better than the OS data per se. Also given that the errors introduced by tracing OS data are exactly the same type of errors introduced by manual OSM surveying, i.e. misspellings in roads, missing roads, outdated roads, ... We need to have the tools to deal with this kind of maintenance anyway. It is the iterations that make OSM data what it is, not the first pass ground survey. Creating a blanket base layer from OS data allows us to much better focus on the aspects that do distinguish us from every other map data provider with having to waste as little as possible resources on the stuff everyone else has too. 2) large scale imports and tracing hinders community growth: This perhaps is the more important of the two arguments, as indeed what distinguishes us from everyone else is the community and without the community and its constant iterations and improvements, OSM data will bit rot just as much as all other data. However I don't think there is any clear evidence either way of what non local mapping does to communities and it remains hotly debated. The negative effects claimed are usually of the form a) The area looks complete, there is nothing more
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?, (Kai Krueger)
On 6 June 2010 22:13, Phil James peerja...@googlemail.com wrote: ...I just feel that blatant, blind copying of OS data is prostituting what I thought Open Street Map was meant to be about./Rant OK, I've got my tin hat on: standing by for incoming... ;-) Phil. I've got a lot of sympathy for that view. The UK map owes a huge amount to individuals trudging along the streets and footpaths/paths/etc of Britain. Mapping Parties have created community, and were responsible for the detailed mapping of many areas. But. OpenStreetMap is a project to create and provide free geographic data, such as streets maps, to anyone who wants them. That is why I contribute. Blatant, blind, copying of OS Data allows us to provide more detailed geographic data which satisfies the aim of the project. The OS data is been treated as a replacement and hard work isnt being deleted. The OS data is only being used to add data that is not currently present, or to mark up blunders. I have no emotional attachment to the data gathering process, whether it be Mapping Parties, Yahoo tracing, or imports. They are simply a means to an end, to be discarded if a better method comes along. The big question is whether importing OS Data means we'll never see the addition of data normally providing by OpenStreetMap streetwalkers. I'd like to think that an almost complete Streetmap will mean a massive increase in use of OpenStreetMap and those new users will add the missing POI. Jason ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Project of the week - trace a village off of OSSV?, (Kai Krueger)
On 7 June 2010 05:18, Jason Cunningham jamicu...@googlemail.com wrote: The OS data is been treated as a replacement and hard work isnt being deleted. The OS data is only being used to add data that is not currently present, or to mark up blunders. Oops, That should have read The OS data is not being treated as a replacement. Thats what happens if you been up all night looking for bats! I'm now now off to get a good days sleep. Jason ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
