Re: [Talk-hr] is_in tag
On Mon, 12 Oct 2009 01:38:45 +0200, nixa wrote: Jel oznacavate bi mjesta s is_in Croatia i is_in:continent Europe? Dosta je stranaca koji su prija mapirali/kartitali po hrvatskoj koristili is_in tag, i sam sam vidjevsi da drugi ga koriste poceo po istoj spranci te tagove koristiti. No dobio sam poruku od iskusnijih mapera izvana da se to vise ne koristi, pa sam shodno tome isao i uklanjao tagove gdje sam ih bio dodao. Mozda je po Slavoniji i okolo jos ostao koji, ali vecinu sam ih klonio. Njegov argument je isto bio da je to zastario nacin mapiranja te da se sada koriste administrativne granice od određivanje gdje je koji grad. -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[Talk-hr] asphalt ili paved?
da li je surface=asphalt legalan tag? Koliko vidim po ovoj stranici: http://wiki.openstreetmap.org/wiki/Proposed_features/more_surface_values Trebao bi se koristiti paved umjesto asphalt? Ili ne? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] is_in tag
On Mon, 12 Oct 2009 07:34:16 +0200, Marjan Vrban wrote: Mislim da su to bespotebni tagovi Sto ih onda nisi uklonio :) Pogledao sam sire podrucje oko slavonije i evo koliko sam nasao is_in tagova i tko ih je postavio, ili zadnji editirao a da nije uklonio: http://dl.getdropbox.com/u/184632/is_in.png i dio POI-a koji su imali is_in tag: http://dl.getdropbox.com/u/184632/is_in_2.png JOSM je mooocan alat za masovno editiranje i ispravljanje tagova, ali takodjer oprez s njegovim koristenjem. Sredio sam taj dio, pogleda cu i ostatak nase lijepe. -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] is_in tag
On Tue, 13 Oct 2009 20:05:29 +0200, Marjan Vrban wrote: Molim da se postojeći ne uklanjaju.. Sto sada? Ostavljamo te tagove ili ne? Ne vidim smisla ako se ne koriste ih ostavljati, pogotovo ako definiramo na wiki-ju da se ne stavljaju, samo cemo zbunjivati nove korisnike koji budu dolazili + imat cemo nekonzistente podatke na razini drzave. Ako cemo ih korisitit onda to treba imati svako mjesto, samo recite pa cu dodati, ali ako nece, onda treba ukloniti sa svakog mjesta. Cak da netko i koristi to nema smisla da bude nekonzistentno, zar ne? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] is_in tag
ja glasam za uklanjanje toga. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[Talk-hr] mkgmap javlja greske
Pri kreiranju garmin karti mkgmap javlja greške, popis se nalazi u privitku. Pomozite mi da ih riješimo. SEVERE (RoadNetwork): Road L67038 (OSM id 39905820) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.70597lon=16.67997zoom=17 SEVERE (RoadNetwork): Road Bikcevic trail (OSM id 17263219) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.89654lon=15.97391zoom=17 SEVERE (RoadNetwork): Road null (OSM id 17263226) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.90281lon=15.98348zoom=17 SEVERE (RoadNetwork): Road null (OSM id 17263226) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.90320lon=15.98354zoom=17 SEVERE (RoadNetwork): Road Trg Nikole Å ubiÄa Zrinskog (OSM id 8139081) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.81056lon=15.97755zoom=17 SEVERE (RoadNetwork): Road AniÄeva (OSM id 29021061) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.77374lon=15.95859zoom=17 SEVERE (RoadNetwork): Road Andrije KaÄiiÄa MioÅ¡iÄa (OSM id 39314720) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.70211lon=16.63682zoom=17 SEVERE (RoadNetwork): Road null (OSM id 42141746) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.42999lon=15.50368zoom=17 SEVERE (RoadNetwork): Road null (OSM id 42141748) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.42999lon=15.50368zoom=17 SEVERE (RoadNetwork): Road L67039 (OSM id 42296164) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.69853lon=16.69040zoom=17 SEVERE (RoadNetwork): Road Ukrajinska (OSM id 29022037) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.77252lon=15.99094zoom=17 SEVERE (RoadNetwork): Road null (OSM id 25460085) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.90281lon=15.98348zoom=17 SEVERE (RoadNetwork): Road null (OSM id 25460085) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.90320lon=15.98354zoom=17 SEVERE (RoadNetwork): Road Bikcevic trail (OSM id 25460088) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.89654lon=15.97391zoom=17 SEVERE (RoadNetwork): Road null (OSM id 31002511) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.49280lon=15.53503zoom=17 SEVERE (RoadNetwork): Road 126.brigade Hrvatske vojske (OSM id 42407183) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.69997lon=16.63540zoom=17 SEVERE (RoadNetwork): Road D1 Bana JelaÄiÄa (OSM id 42409228) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.69454lon=16.64075zoom=17 SEVERE (RoadNetwork): Road D1 ZagrebaÄka ulica (OSM id 42409046) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.70451lon=16.64251zoom=17 SEVERE (RoadNetwork): Road null (OSM id 35073528) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.56183lon=18.67671zoom=17 SEVERE (RoadNetwork): Road BraÄe RadiÄ (OSM id 39159525) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.70531lon=16.63504zoom=17 SEVERE (RoadNetwork): Road null (OSM id 27245317) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.18711lon=13.59105zoom=17 SEVERE (RoadNetwork): Road Bazana (OSM id 40377403) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.69692lon=16.63993zoom=17 SEVERE (RoadNetwork): Road null (OSM id 37490826) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.05753lon=13.70366zoom=17 SEVERE (RoadNetwork): Road Kuparska (OSM id 37448661) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=42.64354lon=18.10214zoom=17 SEVERE (RoadNetwork): Road Velika cesta (OSM id 29707573) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.73887lon=15.99807zoom=17 SEVERE (RoadNetwork): Road null (OSM id 25689794) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.06746lon=13.63822zoom=17 SEVERE (RoadNetwork): Road Žrtava FaÅ¡izma (OSM id 35836938) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.32811lon=14.44488zoom=17 SEVERE (RoadNetwork): Road Velika ulica (OSM id 6281339) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=45.31702lon=13.55973zoom=17 SEVERE (RoadNetwork): Road null (OSM id 40808691) contains zero length arc SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=43.70082lon=16.68411zoom=17 SEVERE
Re: [Talk-hr] asphalt ili paved?
On Tue, 13 Oct 2009 20:55:25 +0200, Matija Nalis wrote: hm, ne ? To gore sto navodis je proposal u statusu Abandoned. A i dok je bio aktivan namjera mu je bila samo prosiriti skup vrijednosti, AFAICT. Originalna stranica za taj tag je: http://wiki.openstreetmap.org/wiki/Key:surface koja ga uredno navodi... Mea culpa, sada vidim da sam fulao u citanju wikija, moj fail. paved/unpaved su grube vrijednosti, ako ne znas precizinije (kao asphalt, concrete, wood, sand...) Ok, eto jos jedan tag za koji cemo se svi sloziti kako ga koristiti, dakle ima tko prijedlog kako oznaciti pravilno cestu? surface=asphalt je onda za 95% cesta koje su primary, secundary ili tertiray oznaka s kojom se ne moze promasiti ili? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Kvartovi u place=town
On Wed, Sep 16, 2009 at 07:04:32PM +, Valent Turkovic wrote: On Wed, 16 Sep 2009 18:45:49 +, Valent Turkovic wrote: Gradske četvrti su administrativne zone i obično jasno definirane unutar gradova. No mozda sam u krivu pa se gradske cetvrti drugacije oznacavaju, ima li tko ideju? Nasao sam kako se oznacavaju gradske cetvrti: http://wiki.openstreetmap.org/wiki/ Key:boundary#10_admin_level_values_for_specific_countries BTW, pokusavam malo to sve dokumentirati sto se dogovorimo na listi, pa sad dodajem upute za oznacavanje gradova, kvartova itd na karti i u wikiju na http://tinyurl.com/ykejzkc imamo li nekih primjera kako su nam oznacene cetvrti i kvartovi na karti ? koji boundary= se koristi u HR ? -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] asphalt ili paved?
Valent Turkovic wrote: surface=asphalt je onda za 95% cesta koje su primary, secundary ili tertiray oznaka s kojom se ne moze promasiti ili? ja inace ceste oznacim samo s highway i ne stavljam nikakav surface, eventualno ako je cesta makadam onda stavim highway=track, tracktype i surface=compacted ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Kvartovi u place=town
On Tue, Oct 13, 2009 at 10:26:03PM +0200, Marjan Vrban wrote: On Tue, 13 Oct 2009 22:13:30 +0200, Matija Nalis wrote: BTW, pokusavam malo to sve dokumentirati sto se dogovorimo na listi, pa sad dodajem upute za oznacavanje gradova, kvartova itd na karti i u wikiju na http://tinyurl.com/ykejzkc imamo li nekih primjera kako su nam oznacene cetvrti i kvartovi na karti ? koji boundary= se koristi u HR ? Jesi pogledo http://wiki.openstreetmap.org/wiki/Key:admin_level#10_admin_level_values_for_specific_countries nisam, tnx. Idem to ukomponirati i polinkati. BTW, nisam imao pojma da je to toliko kompleksno :) imamo znaci (ako sam dobro pohvatao): Drzava Hrvatska (kom.1) == zupanije (kom.21) == gradovi(kom.127) == opcine(kom.429) == gradske cetvrti (kom.17 u Zg) == kvartovi (red velicine 100ak u Zg) Ima li jos nesto da fali ? Vidim da si naveo Hrvatsku drzavnu granicu (admin_level=2), zupanije (level=4), statisticke regije (sto god to bilo, level=5), opcine (level=8), kvartove (level=10) A gdje su tu gradovi ? Mozda su oni statisticke regije ? Ili su oni negdje izmedju (6 ? 7 ?) gradske cetvrti bi mogle biti onda level=9 ? -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Kvartovi u place=town
http://wiki.openstreetmap.org/wiki/Key:admin_level#10_admin_level_values_for_specific_countries nisam, tnx. Idem to ukomponirati i polinkati. BTW, nisam imao pojma da je to toliko kompleksno :) imamo znaci (ako sam dobro pohvatao): Drzava Hrvatska (kom.1) == zupanije (kom.21) == gradovi(kom.127) == opcine(kom.429) == gradske cetvrti (kom.17 u Zg) == kvartovi (red velicine 100ak u Zg) Ima li jos nesto da fali ? Vidim da si naveo Hrvatsku drzavnu granicu (admin_level=2), zupanije (level=4), statisticke regije (sto god to bilo, level=5), opcine (level=7), gradovi,sela (8) četvrti (9) kvartovi (level=10) A gdje su tu gradovi ? Mozda su oni statisticke regije ? Ili su oni negdje izmedju (6 ? 7 ?) gradske cetvrti bi mogle biti onda level=9 ? Ažurirano na: (level=4), statisticke regije (sto god to bilo, level=5), opcine (level=7), gradovi,sela (8), četvrti (9), kvartovi (level=10) ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[talk-ph] efcos and flood monitoring thoughts
Just sharing: My incoherent thoughts on EFCOS and the state of flood monitoring in Metro Manila http://epsg4253.wordpress.com/2009/10/13/free-our-data-rainfall-and-water-level-monitoring/ -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-si] vzdrževanje SI:Garmin_Map
Živijo, Jaz lahko ponudim gostovanje datotek na našem strežniku (Fakulteta za računalništvo in informatiko). Lahko ponudim tudi virtualni linux strežnik za avtomatsko generiranje map, če je kdo pripravlje namestiti in skonfigurirati programsko opremo. LP Martin 2009/10/12 Igor Brejc igor.br...@gmail.com: Zdravo, Ali je kdo od vas zainteresiran, da bi prevzel vzdrževanje Garmin mape za Slovenijo? Sam namreč imam dosti drugih OSM-obveznosti in se redko spomnim, da bi updatal mapo. Poleg tega je problem, da so na OSMXAPI omejili količino podatkov ki jih lahko downloadaš v enem kosu in zdaj ne zadostuje niti razdelitev Slovenije na 4 kose. Idealno bi bilo, če bi ta kandidat imel dostop do kakšnega zastonj server hostinga, da lahko tam drži Garmin mape (cca 20-30 MB) za downloadat. Npr. kakšen hosting z naših fakultet, da lahko tudi mi malo izkoristimo (naš/javni) denar. Jaz lahko providam vse potrebne skripte in SW za generiranje map (teoretično dela tudi na Linuxu). Samega dela ni veliko, mogoče je največ z updatanjem SLO OSM podatkov, vendar se tudi to da avtomatizirati, če postavite PostGIS bazo (tukaj lahko pomagam z izkušnjami). Lep pozdrav, Igor -- http://igorbrejc.net ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [Talk-si] vzdrževanje SI:Garmin_Map
Igor Brejc pravi: Ali je kdo od vas zainteresiran, da bi prevzel vzdrževanje Garmin mape za Slovenijo? Sam namreč imam dosti drugih OSM-obveznosti in se redko spomnim, da bi updatal mapo. Poleg tega je problem, da so na OSMXAPI omejili količino podatkov ki jih lahko downloadaš v enem kosu in zdaj ne zadostuje niti razdelitev Slovenije na 4 kose. Javljam se za to dolžnost, a opozarjam, da sem v OSM začetnik in še niti vseh pojmov ne poznam. Zaenkrat sem: (a) reproduciral postopek po navodilih iz http://wiki.openstreetmap.org/wiki/GroundTruth_For_Dummies na manjšem delu osrednje Slovenije in (b) ugotovil, da za celo Slovenijo (-b 45,13,47,17) strežnik javlja napako, ki potem zmede makemap: errorQuery limit of 1,000,000 elements reached/error. Kako lahko združim posebej pobrane kose v output.osm (omenjaš 4)? Jaz lahko providam vse potrebne skripte in SW za generiranje map (teoretično dela tudi na Linuxu). Samega dela ni veliko, mogoče je največ z updatanjem SLO OSM podatkov, vendar se tudi to da avtomatizirati, če postavite PostGIS bazo (tukaj lahko pomagam z izkušnjami). Pri tem bi te prosil za pomoč oz. usmeritev na kakšna navodila. Martin Vuk pravi: Jaz lahko ponudim gostovanje datotek na našem strežniku (Fakulteta za računalništvo in informatiko). Lahko ponudim tudi virtualni linux strežnik za avtomatsko generiranje map, če je kdo pripravlje namestiti in skonfigurirati programsko opremo. Za gostovanje datotek se priporočam. Z avtomatskim generiranjem map misliš nekaj takega, kar bi moral biti http://cassini.toolserver.org/tile-browse/browse-sl.html , če bi bil pogosteje osveževan? -- Pozdrav, Roman ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [Talk-si] vzdrževanje SI:Garmin_Map
Hojla! Če resursi niso pretirano omejujoči bi lahko: - vzdrževali lokalno kopijo podatkov (izseka do celih stopinj v postgres/postgis bazi) - hosting openstreetmap.si z zemljevidom tega področja (s srtm izohipsami) - mapnik rendering zemljevida s prioriteto name:sl variantam imen (zna biti zanimivo v obmejnih področjih) - arhiv izsekov osm podatkov (npr tedenski ali mesečni dump področja, da se vidi rast) - podatki v drugih oblikah (garmin img, navit...pač po potrebi in zmožnostih) - izdelave raznih statistik, trendov, tagwatch ipd - študentje bi lahko imeli to kot poligon za svoje projekte na realnih podatkih, zanimivejše dosežke bi lahko predstavili na spletu (tudi v živo s trenutnimi podatki) ... Bi ta virtualka bila od zunaj dosegljiva prek porta 80? Kakšne bi bile omejitve (disk, ram...) in ali bi se jih dalo po potrebi dvigniti? lp, Štefan 2009/10/13 Roman Maurer roman.mau...@amis.net: Igor Brejc pravi: Ali je kdo od vas zainteresiran, da bi prevzel vzdrževanje Garmin mape za Slovenijo? Sam namreč imam dosti drugih OSM-obveznosti in se redko spomnim, da bi updatal mapo. Poleg tega je problem, da so na OSMXAPI omejili količino podatkov ki jih lahko downloadaš v enem kosu in zdaj ne zadostuje niti razdelitev Slovenije na 4 kose. Javljam se za to dolžnost, a opozarjam, da sem v OSM začetnik in še niti vseh pojmov ne poznam. Zaenkrat sem: (a) reproduciral postopek po navodilih iz http://wiki.openstreetmap.org/wiki/GroundTruth_For_Dummies na manjšem delu osrednje Slovenije in (b) ugotovil, da za celo Slovenijo (-b 45,13,47,17) strežnik javlja napako, ki potem zmede makemap: errorQuery limit of 1,000,000 elements reached/error. Kako lahko združim posebej pobrane kose v output.osm (omenjaš 4)? Jaz lahko providam vse potrebne skripte in SW za generiranje map (teoretično dela tudi na Linuxu). Samega dela ni veliko, mogoče je največ z updatanjem SLO OSM podatkov, vendar se tudi to da avtomatizirati, če postavite PostGIS bazo (tukaj lahko pomagam z izkušnjami). Pri tem bi te prosil za pomoč oz. usmeritev na kakšna navodila. Martin Vuk pravi: Jaz lahko ponudim gostovanje datotek na našem strežniku (Fakulteta za računalništvo in informatiko). Lahko ponudim tudi virtualni linux strežnik za avtomatsko generiranje map, če je kdo pripravlje namestiti in skonfigurirati programsko opremo. Za gostovanje datotek se priporočam. Z avtomatskim generiranjem map misliš nekaj takega, kar bi moral biti http://cassini.toolserver.org/tile-browse/browse-sl.html , če bi bil pogosteje osveževan? -- Pozdrav, Roman ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
[OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267)
As I suspected the OS has taken a hard line with respect to copyright and publication date. Cheers Andy -Original Message- From: Customer Services [mailto:customerservi...@ordnancesurvey.co.uk] Sent: 13 October 2009 2:10 PM To: blackadder...@googlemail.com Subject: Crown copyright dates ( OS Reference 72267) Dear Mr Robinson Ordnance Survey reference: 72267 Thank you for your email dated 30 September 2009 requesting: seeking clarification regarding Crown Copyright status for those Ordnance Survey map sheets which do not carry a specific Crown Copyright (c) date. Please provide confirmation of the date when, for the following hard copy printed map sheet examples, Crown Copyright expired or will expire. Example 1: 1:25,000 First Series. Sheet SU93. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1948. Reprinted with minor corrections 1960. Example 2: 1:25,000 First Series. Sheet NY21. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1956. Reprinted with minor changes 1963. Example 3: 1:25,000 First Series. Sheet SO98. Print edition B///*. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1953. Reprinted with the addition of new major roads 1967. We are pleased to provide you with the following information with regard to your request. Crown copyright is retained for 50 years from the end of the year in which the last date of publication on, in this instance, an Ordnance Survey map is stated. In the examples provided this means for example 1, from 31 December 1960 until the end of 2010; example 2 from 31 December 1963 until the end of 2013; and example 3 from 31 December 1967 until the end of 2017. Please note that your enquiry has been processed to Freedom of Information guidelines, though technically this request does not qualify under the FOIA as this is not information which is held. As this is the case, we have determined that in all the circumstances of this case the Public interest consideration (section 17 FOIA) is not applicable in this instance. If you are unhappy with our response, you may raise an appeal to our Appeals Officer at: Complaints Team Customer Service Centre Ordnance Survey Romsey Road SOUTHAMPTON SO16 4GU Please include the reference number above. The Appeals Officer will ensure that the process has been followed correctly, questioning any decisions taken regarding the original response and recommending disclosure of additional information if appropriate. Thank you for your enquiry. Yours sincerely Tony Gray Information Access Manager (Freedom of Information) Ordnance Survey C454, Romsey Road, SOUTHAMPTON, United Kingdom, SO16 4GU Phone: +44 (0)8456 05 05 05 Fax: +44 (0) 23 8079 2615 www.ordnancesurvey.co.uk customerservi...@ordnancesurvey.co.uk This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267)
Doesn't this appear to contradict the advice given to Tim SC here? http://wiki.openstreetmap.org/wiki/User:TimSC/CopyrightFOI PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk-boun...@openstreetmap.org] On Behalf Of Andy Robinson (blackadder-lists) Sent: 13 October 2009 15:33 To: 'Licensing and other legal discussions.' Subject: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) As I suspected the OS has taken a hard line with respect to copyright and publication date. Cheers Andy -Original Message- From: Customer Services [mailto:customerservi...@ordnancesurvey.co.uk] Sent: 13 October 2009 2:10 PM To: blackadder...@googlemail.com Subject: Crown copyright dates ( OS Reference 72267) Dear Mr Robinson Ordnance Survey reference: 72267 Thank you for your email dated 30 September 2009 requesting: seeking clarification regarding Crown Copyright status for those Ordnance Survey map sheets which do not carry a specific Crown Copyright (c) date. Please provide confirmation of the date when, for the following hard copy printed map sheet examples, Crown Copyright expired or will expire. Example 1: 1:25,000 First Series. Sheet SU93. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1948. Reprinted with minor corrections 1960. Example 2: 1:25,000 First Series. Sheet NY21. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1956. Reprinted with minor changes 1963. Example 3: 1:25,000 First Series. Sheet SO98. Print edition B///*. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1953. Reprinted with the addition of new major roads 1967. We are pleased to provide you with the following information with regard to your request. Crown copyright is retained for 50 years from the end of the year in which the last date of publication on, in this instance, an Ordnance Survey map is stated. In the examples provided this means for example 1, from 31 December 1960 until the end of 2010; example 2 from 31 December 1963 until the end of 2013; and example 3 from 31 December 1967 until the end of 2017. Please note that your enquiry has been processed to Freedom of Information guidelines, though technically this request does not qualify under the FOIA as this is not information which is held. As this is the case, we have determined that in all the circumstances of this case the Public interest consideration (section 17 FOIA) is not applicable in this instance. If you are unhappy with our response, you may raise an appeal to our Appeals Officer at: Complaints Team Customer Service Centre Ordnance Survey Romsey Road SOUTHAMPTON SO16 4GU Please include the reference number above. The Appeals Officer will ensure that the process has been followed correctly, questioning any decisions taken regarding the original response and recommending disclosure of additional information if appropriate. Thank you for your enquiry. Yours sincerely Tony Gray Information Access Manager (Freedom of Information) Ordnance Survey C454, Romsey Road, SOUTHAMPTON, United Kingdom, SO16 4GU Phone: +44 (0)8456 05 05 05 Fax: +44 (0) 23 8079 2615 www.ordnancesurvey.co.uk customerservi...@ordnancesurvey.co.uk This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@itn.co.uk Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages
Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267)
I'm comfortable that the OS has spoken. A map published with a (c) date means the (c) date applies and if no (c) date printed then the last publication date on the sheet applies. At least we have a basis to move on though I think we could still appeal this latest FOIA response. Cheers Andy -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk- boun...@openstreetmap.org] On Behalf Of Barnett, Phillip Sent: 13 October 2009 3:47 PM To: 'Licensing and other legal discussions.' Subject: Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) Doesn't this appear to contradict the advice given to Tim SC here? http://wiki.openstreetmap.org/wiki/User:TimSC/CopyrightFOI PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk- boun...@openstreetmap.org] On Behalf Of Andy Robinson (blackadder-lists) Sent: 13 October 2009 15:33 To: 'Licensing and other legal discussions.' Subject: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) As I suspected the OS has taken a hard line with respect to copyright and publication date. Cheers Andy -Original Message- From: Customer Services [mailto:customerservi...@ordnancesurvey.co.uk] Sent: 13 October 2009 2:10 PM To: blackadder...@googlemail.com Subject: Crown copyright dates ( OS Reference 72267) Dear Mr Robinson Ordnance Survey reference: 72267 Thank you for your email dated 30 September 2009 requesting: seeking clarification regarding Crown Copyright status for those Ordnance Survey map sheets which do not carry a specific Crown Copyright (c) date. Please provide confirmation of the date when, for the following hard copy printed map sheet examples, Crown Copyright expired or will expire. Example 1: 1:25,000 First Series. Sheet SU93. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1948. Reprinted with minor corrections 1960. Example 2: 1:25,000 First Series. Sheet NY21. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1956. Reprinted with minor changes 1963. Example 3: 1:25,000 First Series. Sheet SO98. Print edition B///*. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1953. Reprinted with the addition of new major roads 1967. We are pleased to provide you with the following information with regard to your request. Crown copyright is retained for 50 years from the end of the year in which the last date of publication on, in this instance, an Ordnance Survey map is stated. In the examples provided this means for example 1, from 31 December 1960 until the end of 2010; example 2 from 31 December 1963 until the end of 2013; and example 3 from 31 December 1967 until the end of 2017. Please note that your enquiry has been processed to Freedom of Information guidelines, though technically this request does not qualify under the FOIA as this is not information which is held. As this is the case, we have determined that in all the circumstances of this case the Public interest consideration (section 17 FOIA) is not applicable in this instance. If you are unhappy with our response, you may raise an appeal to our Appeals Officer at: Complaints Team Customer Service Centre Ordnance Survey Romsey Road SOUTHAMPTON SO16 4GU Please include the reference number above. The Appeals Officer will ensure that the process has been followed correctly, questioning any decisions taken regarding the original response and recommending disclosure of additional information if appropriate. Thank you for your enquiry. Yours sincerely Tony Gray Information Access Manager (Freedom of Information) Ordnance Survey C454, Romsey Road, SOUTHAMPTON, United Kingdom, SO16 4GU Phone: +44 (0)8456 05 05 05 Fax: +44 (0) 23 8079 2615 www.ordnancesurvey.co.uk customerservi...@ordnancesurvey.co.uk This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk ___ legal-talk mailing list
[OSM-talk] State of the Map 2010 - Where?
State of the Map 2009 is now several months behind us. Thanks to all the people who where there (either in person or virtual) we can look back on three awesome days. It showed what a wonderfull bunch of people we are! It's time to think about the next State of the Map, SotM10. During the last conference there have been an informal vote on the location of next years event. Several places where mentioned including the ranch of former president George Bush or a Lidl supermarket. We apparently do not only want our data to be used in unexpected ways but also want to have our conference at unexpected locations! Now it's time to work on the next location/venue of the State of the Map. Do you want to have this international conference in your favorite country/city? Let's hear it! The call for bids is now open at http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2010/Bid Cheers, Henk Hoff State of the Map 2010 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
Hello everybody, I propose to add a tag boundary=military : the problem is that, with the existing tags, it's almost impossible to mark correctly lots of data, like (non limitative list) forest, scholl, parking lot, Rather than multiplying the military=* tag, I suggest to only mark the external limit of the military area. http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base Comments are welcomed on http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Military_base Gilles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Instead of voting
2009/10/12 James Livingston doc...@mac.com: If there is a wiki page which describes a tag in a limited way, and I want to document how I've used it, what should I be doing? IMHO you should either try to find out that your definition of the tag is the one the majority of mappers supports (and uses), or you should invent another tag. * edit the main page, which could annoy the people who created the page +1, you shouldn't do this without discussing it first if you are changing the actual meaning of a tag, or better: you should invent another tag to describe what you want to express. * add a note to the discussion page, which someone searching the wiki for how to tag things won't read +1 * create a new page describing my version, which leads to conflicting information no, this is IMHO counterproductive, as different pages with different content/definition for the same tag will 100% lead to chaos. IMHO you should generally invent a new tag if possible. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visual map for the blind
2009/10/12 lulu-...@gmx.de: What tag would you use for bus/tram stops with a i button that reads out the information about trams soonest to arrive, aloud? I have never seen those before. Not proposed yet, but I guess many things need explanation, so I would tag it like that: tourism=information information=acoustic_text description:en:blind=There is an information button that reads out schedule times It doesn't seem like a tourism thing to me, wouldn't they be designed for people that live in the area? Well, ordinary maps and tactile maps are used by people living in that area, too, but the information tag is placed in tourism. That does not matter, because we can display elements from any namespaces on any map. while this is true, it might still facilitate life for editor-creators and data-consumers as for mappers to have all these kind of tag subsummarized in one big tag like k=disabled v=* or k=accessibility, v=* so you can easily find them in one rubrique instead of searching all over the wiki in different tags and pages. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Google has dual carriage way where it's not built yet
2009/10/12 Ben Laenen benlae...@gmail.com: I made a proposal: http://wiki.openstreetmap.org/wiki/Key:planned So what's the difference with highway=proposed + proposed=...? I can't seem to find the wiki page, but highway=proposed is already in use and it's rendered in the Mapnik layer. maybe this one? http://wiki.openstreetmap.org/wiki/Proposed_features/Road/Rail_proposed there's also an inactive duplicate here: http://wiki.openstreetmap.org/wiki/Proposed_features/Proposed there's a big difference: my proposal doesn't break rendering for renderers/routers/other consumers that don't know the tag planned, while the linked proposal breaks it by rendering a proposed street like an already built one in case it doesn't know the specific tag! cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
Am 12.10.2009 01:00, Dave G: Hi It may be a localisation problem or semantics but it appears that alpine hut / regular hut / shelter / etc. definitions or perceptions vary between countryies as previously stated: This is my interpretation of an Alpine Hut - http://en.wikipedia.org/wiki/Mountain_hut In the United Kingdomhttp://en.wikipedia.org/wiki/United_Kingdom and Irelandhttp://en.wikipedia.org/wiki/Ireland the tradition is of unwardened climbing huts providing fairly rudimentary accommodation http://en.wikipedia.org/wiki/Bothy The problem with the is that these definition doesn't fit my situation in New Zealand and we have a network of over 900 back country huts An alpine hut in NZ might look more like this: http://www.doc.govt.nz/parks-and-recreation/places-to-stay/backcountry-huts-by-region/west-coast/franz-josef-area/centennial-hut/ or http://alpineguides.co.nz/info/huts/tasman_saddle.htm but sorry not restaurants!! My intention with my proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings was to create a generic tagging system for buildings, where features are tagged/listed, hopefully to avoid the localisation problems ie. the you say potato, I say potaaato problem ? cheers...gerkin True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? Claudius ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
On 13 Oct 2009, at 12:04, Claudius wrote: True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? A shelter is a really wide ranging thing, from a shelter at a bus stop so that you don't get so wet when it is raining while waiting for the bus, through to what you are stating. How do you tag the differences? For a bus stop there is highway=bus_stop; shelter=yes. What about a railway station, well halt? There are some smaller stations that have a shelter that is a similar style to a bus stop shelter. How should those be tagged when you want to state the location of it along the length of the railway=platform? Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
Hi, True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? Don't know about English but as always the US version is larger: http://www.ohiocaverns.com/shelter.htm building=shelter? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Google has dual carriage way where it's not built yet
Martin Koppenhoefer wrote: 2009/10/12 Ben Laenen benlae...@gmail.com: I made a proposal: http://wiki.openstreetmap.org/wiki/Key:planned So what's the difference with highway=proposed + proposed=...? I can't seem to find the wiki page, but highway=proposed is already in use and it's rendered in the Mapnik layer. maybe this one? http://wiki.openstreetmap.org/wiki/Proposed_features/Road/Rail_proposed no, not this one. there's also an inactive duplicate here: http://wiki.openstreetmap.org/wiki/Proposed_features/Proposed More or less. The syntax is just like your proposal, but instead of using planned, it uses proposed. So either highway=proposed + proposed=primary/secondary/... or railway=proposed + proposed=rail/tram/... Given that Mapnik is already rendering the highway=proposed syntax, it makes sense to just adjust your proposal to use proposed instead of planned. And you don't really need to go through RFC or voting or whatever, because it's basically documenting established use (osmdoc.com currently gives 200 usages of highway=proposed -- which is actually quite a lot for something which is almost unmappable...). Greetings Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
2009/10/13 Frederik Ramm frede...@remote.org: Hi, True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? Don't know about English but as always the US version is larger: http://www.ohiocaverns.com/shelter.htm building=shelter? shelter in english is too ambiguous without knowing the context, how about building=hut ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visual map for the blind
Original-Nachricht Datum: Tue, 13 Oct 2009 12:57:18 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: lulu-...@gmx.de CC: accessibil...@openstreetmap.org, talk@openstreetmap.org, tagg...@openstreetmap.org Betreff: Re: [OSM-talk] Visual map for the blind 2009/10/12 lulu-...@gmx.de: What tag would you use for bus/tram stops with a i button that reads out the information about trams soonest to arrive, aloud? I have never seen those before. Not proposed yet, but I guess many things need explanation, so I would tag it like that: tourism=information information=acoustic_text description:en:blind=There is an information button that reads out schedule times It doesn't seem like a tourism thing to me, wouldn't they be designed for people that live in the area? Well, ordinary maps and tactile maps are used by people living in that area, too, but the information tag is placed in tourism. That does not matter, because we can display elements from any namespaces on any map. while this is true, it might still facilitate life for editor-creators and data-consumers as for mappers to have all these kind of tag subsummarized in one big tag like k=disabled v=* or k=accessibility, v=* so you can easily find them in one rubrique instead of searching all over the wiki in different tags and pages. I would love to agree, but the needs of disabled persons are widely spread over our tagging scheme anyway, and awareness of objects that refer to accessibility is nearly zero. There are categories for visual, hearing and walking impariment, colletcted in the category accessibiliy. The :blind in my proposal as a postfix was an idea to approach what you recommend. Regards Lulu-Ann -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Taggin for the blind [was: Re: Visual map for the blind]
Lulu-Ann wrote: I would love to agree, but the needs of disabled persons are widely spread over our tagging scheme anyway, and awareness of objects that refer to accessibility is nearly zero. There are categories for visual, hearing and walking impariment, colletcted in the category accessibiliy. The :blind in my proposal as a postfix was an idea to approach what you recommend. John proposed: accessibility:blind=* ? This does not help. Tell me the values, and I can tell you if they might work. I guess we will reach all non graphics interfaces, if we use description:language-abbrev.:blind = Description text in whole sentences. so any device can read out a full sentence on the found accessibility means. Regards Lulu-Ann -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
Frederik Ramm wrote: Hi, True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? Don't know about English but as always the US version is larger: http://www.ohiocaverns.com/shelter.htm That first one looks more like a rockery to me. :-) I think that shelter should be used for bus/park etc. The life death seriousness of the high altitude shelters should be noted - something like survival_shelter? The building described with restaurants bedrooms are *not* shelters but hotels. http://en.wikipedia.org/wiki/File:MOko_schronisko.JPG ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
Gilles Corlobé writes: I propose to add a tag boundary=military Where is this tag currently being used? Please point to several examples so we can see what you mean. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetBugs: shared database and translations
I am happy to announce that error reports are now stored in one single database, no matter whether you are using the interface at http://openstreetbugs.org/ or at the Google hosted http://openstreetbugs.appspot.com/. As before, you can download all bugs in a daily dump at http://openstreetbugs.schokokeks.org/dumps/. There is another change in the new interface: Translation support. Currently there is French, Japanese and German available and served if your browser sends the corresponding Accept-Language header. Thanks to Nazotoko and Xav! If you would like to translate the interface to your language, just grab http://openstreetbugs.schokokeks.org/locale/empty.json, fill the empty strings after the colon and send it to me. Please do not forget to mention the ISO code of your language or rename the file accordingly. Cheers, Mitja ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] FOSSGIS 2010 conference: Call for Papers
Hi, the Call for Papers for the FOSSGIS 2010 conference (2-5 March, Osnabrueck, Germany) is out: http://www.fossgis.de/konferenz/wiki/2010/Call_for_Papers This conference is going to be the first major German OSM conference (with a little bit of traditional Open Source GIS stuff at the beginning ;-). Tuesday and Wednesday will be more traditional OS GIS stuff and Thursday and Friday will be dominated by OSM. There will be social events on Tuesday and Thursday night. It will be possible to extend the conference to Saturday if e.g. some teams would like to hold a coding sprint or something, but we're unlikely to have any talks on Saturday. International visitors and speakers are welcome. The programme committee has the following message for international speakers: FOSSGIS is a German-language conference primarily for a German audience. The program committee will, however, also consider applications for talks or workshops held in English if they are deeemed to add to the quality of the conference. So if you don't speak German, but are a FOSS/Open Data celebrity, or have a story that only you can tell, please do submit your talk. We are unlikely to be able to provide interpreters, but we'll make sure you don't get lost in Germany. Submission of talks is done using the widely used Pentabarf software which defaults to German but can be switched to English by the submitting user: http://pb.fossgis.de/submission/FOSSGIS2010 For the OSM part, we're looking for all kinds of interesting talks - about mapping, about the use of OSM in various contexts, about cool bits of software you have written or why you think OSM is never going to work. We're planning to have 30-minute talks (including discussion) but if you need more time or less, just note it. Please note that FOSSGIS is an Open Source conference. The programme committee will not normally consider talks that focus on proprietary software, although exceptions may be made when OSM is concerned (How to use an $5k Illustrator Plugin to create nice OSM maps would be such a corner case). I'm happy to answer any questions you might have, or put you in touch with the people who can. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
-Message d'origine- De : Russ Nelson [mailto:nel...@crynwr.com] Envoyé : mardi 13 octobre 2009 16:38 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) Gilles Corlobé writes: I propose to add a tag boundary=military Where is this tag currently being used? Please point to several examples so we can see what you mean. This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Inside the miltary area, there is : a forest, a research center, a high-school, a sport complexe with swiming pool, a parking lot, and accomodations for all the seamen (it's a navy facility). Gilles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
On Tue, Oct 13, 2009 at 7:04 AM, Claudius claudiu...@gmx.de wrote: True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? I'd call it a hut. I suppose it's technically a shelter, but from the description you gave, before I clicked on the link, I wasn't expecting something with four walls. A shelter is anything with a roof. It might have 0 walls, or it might have more walls, but if it has four walls I'd generally use a more descriptive name for it. I'm williing to go with the majority though. Right now, I'm tagging picnic-type shelters (see http://www.ci.burlington.wa.us/imageuploads/Media-322.jpg) as amenity=shelter. This looks dumb when zooming in on the map, but I don't tag for the renderers :). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
On 13 Oct 2009, at 16:35, Gilles Corlobé wrote: -Message d'origine- De : Russ Nelson [mailto:nel...@crynwr.com] Envoyé : mardi 13 octobre 2009 16:38 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) Gilles Corlobé writes: I propose to add a tag boundary=military Where is this tag currently being used? Please point to several examples so we can see what you mean. This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Inside the miltary area, there is : a forest, a research center, a high-school, a sport complexe with swiming pool, a parking lot, and accomodations for all the seamen (it's a navy facility). Before you propose a tag, you should be using it. Do you have any photos of this? For example signs. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
-Message d'origine- De : Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] Envoyé : mardi 13 octobre 2009 17:46 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : **SPAM ENGLISH BODY** Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) On 13 Oct 2009, at 16:35, Gilles Corlobé wrote: -Message d'origine- De : Russ Nelson [mailto:nel...@crynwr.com] Envoyé : mardi 13 octobre 2009 16:38 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) Gilles Corlobé writes: I propose to add a tag boundary=military Where is this tag currently being used? Please point to several examples so we can see what you mean. This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Inside the miltary area, there is : a forest, a research center, a high-school, a sport complexe with swiming pool, a parking lot, and accomodations for all the seamen (it's a navy facility). Before you propose a tag, you should be using it. Do you have any photos of this? For example signs. Shaun The photo on the page http://wiki.openstreetmap.org/wiki/Proposed_features/Military_area commes from there. And before using it, I wanted to get its approval from the community. But if it's ok, I'll do it. Gilles smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
Gilles Corlobé writes: This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Why wait? Tag boldly and document what you did in the wiki. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
-Message d'origine- De : talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] De la part de Russ Nelson Envoyé : mardi 13 octobre 2009 17:54 À : talk@openstreetmap.org Objet : **SPAM ENGLISH BODY** Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) Gilles Corlobé writes: This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Why wait? Tag boldly and document what you did in the wiki. I didn't know I didn't have to wait the approval. It's now done : http://osm.org/go/xXEahwWz-- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
On Tue, Oct 13, 2009 at 5:53 PM, Russ Nelson nel...@crynwr.com wrote: Why wait? Tag boldly and document what you did in the wiki. No, no and no. If you are unsure or unhappy with existing tags, then document, suggest and discuss before putting crap in OSM ! Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TIGER Addressing Import
Dave - super awesome. As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. Another random thought - should the addressing ways be one long way with two nodes per block, or lots of two node ways? My immediate preference is for the former...? Also - the ways will be deplaced 90 degress to the road centerline to push them to the edge of the road I assume - but you also need to 'pull in' the end nodes too so they are not laying on top of the cross streets at each end, if you see what I mean? Yours c. Steve On 3 Oct 2009, at 09:13, Dave Hansen wrote: Is this the most up to date way of keeping addresses? http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Well, I have some perl code that will parse the 2007/2008 TIGER data files. My goal is to get the addresses imported into OSM this time around. Here's some ugly sample output of what I have now. http://sr71.net/~dave/osm/tiger/sherman.osm I don't need any suggestions on it, I just wanted to show people what I have so far. Issues: * I currently have the way combination code turned off. This means that OSM ways are represented 1:1 with the TIGER TLIDs. * Some multi-segment TIGER roads have only a single address range. Do we create segments for each road segment and evenly divide the addresses? Or, do we draw a single address segment going from the first to last node? And, yes, I saw the 2009 data come out. I'll make sure my code works with it. -- Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TIGER Addressing Import
On Tue, Oct 13, 2009 at 18:20, SteveC st...@asklater.com wrote: As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. dont you think we need a simple way to check-in check-out files from such a big effort? something that will enable people to interact with the files. something visual as this http://osm.m0nty.de/ used in bayern for the aerial images? or am am I too old to be able to think about complex wiki pages? -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/14 Pieren pier...@gmail.com: 2009/10/13 Gilles Corlobé gil...@corlobe.tk: I didn't know I didn't have to wait the approval. It's now done : http://osm.org/go/xXEahwWz-- Gilles, your approach was the correct one. Don't follow those stupid advices from guys how want the chaos in OSM. Making proposals and having discussions will show you if you are in the good way or not. And if your first idea was wrong, you don't have to revert your edits. Or update the same thing 10 times because once you do tag and update people will say it's wrong and you should have done it some other way... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TIGER Addressing Import
On 13 Oct 2009, at 09:26, Simone Cortesi wrote: On Tue, Oct 13, 2009 at 18:20, SteveC st...@asklater.com wrote: As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. dont you think we need a simple way to check-in check-out files from such a big effort? maybe... but right now the blocker is dave having enough time... I suggest we guilt trip him by buying him things off his amazon wishlist or something :-) something that will enable people to interact with the files. something visual as this http://osm.m0nty.de/ used in bayern for the aerial images? or am am I too old to be able to think about complex wiki pages? yeah I get the point, but I'd prefer to cross the first hurdle, which is having some files to look at Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] TIGER Addressing Import
On 13 Oct 2009, at 9:20 , SteveC wrote: Dave - super awesome. As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. yes this is the best way to get as many mappers as possible involved. check for errors ... Another random thought - should the addressing ways be one long way with two nodes per block, or lots of two node ways? My immediate preference is for the former...? Also - the ways will be deplaced 90 degress to the road centerline to push them to the edge of the road I assume - but you also need to 'pull in' the end nodes too so they are not laying on top of the cross streets at each end, if you see what I mean? Yours c. Steve On 3 Oct 2009, at 09:13, Dave Hansen wrote: Is this the most up to date way of keeping addresses? http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Well, I have some perl code that will parse the 2007/2008 TIGER data files. My goal is to get the addresses imported into OSM this time around. Here's some ugly sample output of what I have now. http://sr71.net/~dave/osm/tiger/sherman.osm I don't need any suggestions on it, I just wanted to show people what I have so far. Issues: * I currently have the way combination code turned off. This means that OSM ways are represented 1:1 with the TIGER TLIDs. * Some multi-segment TIGER roads have only a single address range. Do we create segments for each road segment and evenly divide the addresses? Or, do we draw a single address segment going from the first to last node? And, yes, I saw the 2009 data come out. I'll make sure my code works with it. -- Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267)
Andy, Crown copyright maps, and books, are reprinted all the time. Copyright dates stay the same, generally. The crux point is what triggers a new copyright date. Guidance notes from the OPSI - A new edition of a published work which contains substantial revisions would normally qualify as a new copyright work. For example, if a department first published a document in 1997 and subsequently revised and reissued it in 2004, the notice in the revised version would indicate the copyright date of 2004, although it would be customary - and helpful - to state that an earlier version had been issued in 1997. A reprint or new impression without any substantial changes to the text would not constitute a new copyright work. The last sentence is the important one - of the examples that you sent to them below, all explicitly claim 'minor' changes to the work, and so the OPSI guidelines indicate that no copyright date change would be the case, which is presumably why the maps were never printed with a revised copyright date in the first place. 'Reprinted with minor corrections 1960' 'Reprinted with minor changes 1963.' 'Reprinted with the addition of new major roads 1967.' - this one is possibly debateable as it contains the word 'major' - substitute 'A roads' for 'major roads' and I contend it qualifies as minor changes. So the situation should be - A map published with a (c) date means the (c) date applies and if no (c) date printed then the FIRST publication date on the sheet applies. And we have plenty of examples collected of where the revision date is later than the explicitly printed copyright date, which rather proves my point. (eg my copy of SO13, Talgarth, (c) 1951, major road revisions 1976) Now, who's going to take this up with Tony Gray? (I'm happy to argue the point, if you don't mind my quoting your correspondence. Otherwise I'll just point him to the OPSI guidance) Cheers Phillip -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk-boun...@openstreetmap.org] On Behalf Of Andy Robinson (blackadder-lists) Sent: 13 October 2009 15:59 To: 'Licensing and other legal discussions.' Subject: Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) I'm comfortable that the OS has spoken. A map published with a (c) date means the (c) date applies and if no (c) date printed then the last publication date on the sheet applies. At least we have a basis to move on though I think we could still appeal this latest FOIA response. Cheers Andy -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk- boun...@openstreetmap.org] On Behalf Of Barnett, Phillip Sent: 13 October 2009 3:47 PM To: 'Licensing and other legal discussions.' Subject: Re: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) Doesn't this appear to contradict the advice given to Tim SC here? http://wiki.openstreetmap.org/wiki/User:TimSC/CopyrightFOI PHILLIP BARNETT SERVER MANAGER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4474 F E phillip.barn...@itn.co.uk http://WWW.ITN.CO.UK P Please consider the environment. Do you really need to print this email? -Original Message- From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk- boun...@openstreetmap.org] On Behalf Of Andy Robinson (blackadder-lists) Sent: 13 October 2009 15:33 To: 'Licensing and other legal discussions.' Subject: [OSM-legal-talk] FW: Crown copyright dates ( OS Reference 72267) As I suspected the OS has taken a hard line with respect to copyright and publication date. Cheers Andy -Original Message- From: Customer Services [mailto:customerservi...@ordnancesurvey.co.uk] Sent: 13 October 2009 2:10 PM To: blackadder...@googlemail.com Subject: Crown copyright dates ( OS Reference 72267) Dear Mr Robinson Ordnance Survey reference: 72267 Thank you for your email dated 30 September 2009 requesting: seeking clarification regarding Crown Copyright status for those Ordnance Survey map sheets which do not carry a specific Crown Copyright (c) date. Please provide confirmation of the date when, for the following hard copy printed map sheet examples, Crown Copyright expired or will expire. Example 1: 1:25,000 First Series. Sheet SU93. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1948. Reprinted with minor corrections 1960. Example 2: 1:25,000 First Series. Sheet NY21. Print edition C//. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1956. Reprinted with minor changes 1963. Example 3: 1:25,000 First Series. Sheet SO98. Print edition B///*. Made and published by the Director General of the Ordnance Survey, Chessington, Surrey, 1953. Reprinted with the addition of new major roads 1967. We are pleased to provide you with the following information with regard to your request. Crown
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
On 13/10/2009, at 10.14, Gilles Corlobé wrote: Hello everybody, I propose to add a tag boundary=military : the problem is that, with the existing tags, it's almost impossible to mark correctly lots of data, like (non limitative list) forest, scholl, parking lot, … Rather than multiplying the military=* tag, I suggest to only mark the external limit of the military area. http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base Comments are welcomed on http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Military_base To be honest I don't see the point. You should use the already existing landuse=military. School, parking lot, etc. that you mentioned should be rendered on top of that, like landuse=residential. Using landuse also avoids certain ambiguities like: which side of the boundary is the military area? Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] TIGER Addressing Import
On Tue, Oct 13, 2009 at 18:20, SteveC st...@asklater.com wrote: Dave - super awesome. As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. Another random thought - should the addressing ways be one long way with two nodes per block, or lots of two node ways? My immediate preference is for the former...? Although my preference would also be for the former, people will break the ways midblock, for very good reasons. For example, recording a small bridge in the middle of the block would entail splitting the way into three--one for the bridge, and one on each end of it. Most likely, each piece will still carry the full address range, even though the bridge should have none and the range should be split. In Tampa, we also have instances of streets transitioning from 4-lane undivided to 4-lane divided (dual carriageways) midblock. Which raises another issue. The old TIGER files had a single way for most of the dual carriageway major streets in our area. I have not looked at the new 2009 TIGER files, but I suspect that they have similar representations of these streets. When splitting these into two parallel one-way routes, should both then carry the original addressing ranges, or should one carry the odd address numbers and the other carry the even address numbers? Also - the ways will be deplaced 90 degress to the road centerline to push them to the edge of the road I assume - but you also need to 'pull in' the end nodes too so they are not laying on top of the cross streets at each end, if you see what I mean? Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TIGER Addressing Import
On 13 Oct 2009, at 10:37, Hillsman, Edward wrote: On Tue, Oct 13, 2009 at 18:20, SteveC st...@asklater.com wrote: Dave - super awesome. As I said on IRC the other week, but I'll repeat here for all - I think dumping the addressing for all 3,000 counties and then letting people import them one by one will be the best way to do it. Another random thought - should the addressing ways be one long way with two nodes per block, or lots of two node ways? My immediate preference is for the former...? Although my preference would also be for the former, people will break the ways midblock, for very good reasons. For example, recording a small bridge in the middle of the block would entail splitting the way into three--one for the bridge, and one on each end of it. Most likely, each piece will still carry the full address range, even though the bridge should have none and the range should be split. In Tampa, we also have instances of streets transitioning from 4-lane undivided to 4-lane divided (dual carriageways) midblock. Which raises another issue. The old TIGER files had a single way for most of the dual carriageway major streets in our area. I have not looked at the new 2009 TIGER files, but I suspect that they have similar representations of these streets. When splitting these into two parallel one-way routes, should both then carry the original addressing ranges, or should one carry the odd address numbers and the other carry the even address numbers? no... the addressing is on entirely separate parallel ways Also - the ways will be deplaced 90 degress to the road centerline to push them to the edge of the road I assume - but you also need to 'pull in' the end nodes too so they are not laying on top of the cross streets at each end, if you see what I mean? Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] TIGER Addressing Import
2009/10/13 SteveC st...@asklater.com: Also - the ways will be deplaced 90 degress to the road centerline to push them to the edge of the road I assume - but you also need to 'pull in' the end nodes too so they are not laying on top of the cross streets at each end, if you see what I mean? There's some (ugly) python code to do that at [1] that you could adapt, results in [2]. It's easy but involves reprojection to get the 90 degrees right. Cheers 1. http://repo.or.cz/w/ump2osm.git?a=blob;f=txt2osm.py;h=9bf2d713be1894451353b02f47fd0f23b8c6fbd3;hb=HEAD#l922 2. http://www.openstreetmap.org/?lat=52.43863lon=16.82956zoom=17layers=B000FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
On Wed, 14 Oct 2009, Shaun McDonald wrote: Before you propose a tag, you should be using it. Why? Doesn't it make sense to ask around before using something - someone may come up with a good example they are already using, or a simple reason why your tag is not good. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/13 Pieren pier...@gmail.com: 2009/10/13 Gilles Corlobé gil...@corlobe.tk: I didn't know I didn't have to wait the approval. It's now done : http://osm.org/go/xXEahwWz-- Gilles, your approach was the correct one. Don't follow those stupid advices from guys how want the chaos in OSM. Making proposals and having discussions will show you if you are in the good way or not. And if your first idea was wrong, you don't have to revert your edits. +1. But you will have to change the wiki, if your proposal wasn't good, that's why I'd recommend to first ask, than make the proposal, unless you're very sure (I did the same mistake yesterday, btw). actually I still think it's a duplicate that comes from a misunderstanding of the rules, that is, you shouldn't tag 2 landuse=xy to the same object, but of course you can have overlapping ones. I recommend to tag landuse=military, because that's what it is, and probably an appropriate barrier. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik shelter rendering
2009/10/13 Claudius claudiu...@gmx.de: True. In german we say Schutzhütte (losely translates as protection hut) and the german wikipedia article shows good examples in pictures: http://de.wikipedia.org/wiki/Schutzhütte (ignore the one in the lower right corner). These shelters are only used as a protection from bad weather. You won't voluntarily spend a night there and they won't have any facilities or even power supply. Don't you call these shelter in English? How do you know that OSM-shelter is Schutzhütte? It could as well be Unterstand. http://de.wikipedia.org/wiki/Unterstand - thus changing just slightly but still it's meaning. Btw. wikipedia translates Schutzhütte to mountain hut and has no corresponding English article for this. WP-shelter corrisponds to WP-Unterkunft which is surely not the intended meaning here. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
Shaun McDonald wrote: On 13 Oct 2009, at 16:35, Gilles Corlobé wrote: -Message d'origine- De : Russ Nelson [mailto:nel...@crynwr.com] Envoyé : mardi 13 octobre 2009 16:38 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) Gilles Corlobé writes: I propose to add a tag boundary=military Where is this tag currently being used? Please point to several examples so we can see what you mean. This tag is not currently used. But it could be very usefull here : http://osm.org/go/xXEahwWz-- Inside the miltary area, there is : a forest, a research center, a high-school, a sport complexe with swiming pool, a parking lot, and accomodations for all the seamen (it's a navy facility). Before you propose a tag, you should be using it. How?? He's proposing it's introduction for use! If he's already using it then a proposal is pointless!! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
To be honest I don't see the point. You should use the already existing landuse=military. School, parking lot, etc. that you mentioned should be rendered on top of that, like landuse=residential. Using landuse also avoids certain ambiguities like: which side of the boundary is the military area? +1 Perhaps also use a relation to tie various landuses together into a military-base=name group or something similar. If the OP doesn't like how nested landuse is rendered in a specific renderer should they not file a bug with the maintainers of that renderer? Seems better than adding to the db. Joseph 2009/10/13 Morten Kjeldgaard m...@bioxray.au.dk: On 13/10/2009, at 10.14, Gilles Corlobé wrote: Hello everybody, I propose to add a tag boundary=military : the problem is that, with the existing tags, it's almost impossible to mark correctly lots of data, like (non limitative list) forest, scholl, parking lot, … Rather than multiplying the military=* tag, I suggest to only mark the external limit of the military area. http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base Comments are welcomed on http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Military_base To be honest I don't see the point. You should use the already existing landuse=military. School, parking lot, etc. that you mentioned should be rendered on top of that, like landuse=residential. Using landuse also avoids certain ambiguities like: which side of the boundary is the military area? Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
Pieren wrote: 2009/10/13 Gilles Corlobé gil...@corlobe.tk: I didn't know I didn't have to wait the approval. It's now done : http://osm.org/go/xXEahwWz-- Gilles, your approach was the correct one. Don't follow those stupid advices from guys how want the chaos in OSM. Making proposals and having discussions will show you if you are in the good way or not. And if your first idea was wrong, you don't have to revert your edits. +1 Always ask for advice opinion if you're unsure of your suggestions. The just go ahead do it philosophy that some advocate just puts errors into OSM that may not get fully removed, especially if they've been around for a while have been copied by others. Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetBugs: shared database and translations
Mitja Kleider wrote: I am happy to announce that error reports are now stored in one single database, no matter whether you are using the interface at http://openstreetbugs.org/ or at the Google hosted http://openstreetbugs.appspot.com/. Please forgive me if I'm not understanding correctly, but what is the purpose of this site? I looked at the a couple of problems that were listed in my area. It seems to me, if they know the problems then they know the solutions. It would have taken less time for the poster to fix them himself rather than posting to this site asking others to it for them. Or am I missing something? This one seems worth while because even though it doesn't pick up everything, it automatically searches the database. http://keepright.ipax.at/report_map.php Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetBugs: shared database and translations
On Tue, Oct 13, 2009 at 5:52 PM, Dave F. dave...@madasafish.com wrote: Mitja Kleider wrote: I am happy to announce that error reports are now stored in one single database, no matter whether you are using the interface at http://openstreetbugs.org/ or at the Google hosted http://openstreetbugs.appspot.com/. Please forgive me if I'm not understanding correctly, but what is the purpose of this site? I looked at the a couple of problems that were listed in my area. It seems to me, if they know the problems then they know the solutions. It would have taken less time for the poster to fix them himself rather than posting to this site asking others to it for them. Or am I missing something? The point behind openstreetbugs was/is to provide an extremely easy-to-use interface for people outside of the mapping community to bring attention to something that needs to be fixed with the map data. Think of it as an analogue to the Report a problem feature that appeared in the US portion of maps.google.com last week. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetBugs: shared database and translations
El Miércoles, 14 de Octubre de 2009, Shaun McDonald escribió: It's for people who don't know how to edit osm data, or reminders to go and resurvey something by mappers. ... or a reminder to edit that tomorrow, as it's 4 AM and you only think about fixing just one more roundabout. -- -- Iván Sánchez Ortega i...@sanchezortega.es Las palabras son los clavos para fijar las ideas.- A. Godin. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] walking-papers hanging?
Greetings. Is it only my impression or have the walking-pares stopped working over a week ago? -- Było mi bardzo miło. Czwarta pospolita klęska, [...] Łukasz Już nie katolicka lecz złodziejska. (c)PP -- Szukasz pracy? Chcesz lepiej zarabia�? Sprawd� oferty na http://link.interia.pl/f23ba attachment: stlman.vcf___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/14 Dave F. dave...@madasafish.com: Pieren wrote: 2009/10/13 Gilles Corlobé gil...@corlobe.tk: I didn't know I didn't have to wait the approval. It's now done : http://osm.org/go/xXEahwWz-- Gilles, your approach was the correct one. Don't follow those stupid advices from guys how want the chaos in OSM. Making proposals and having discussions will show you if you are in the good way or not. And if your first idea was wrong, you don't have to revert your edits. +1 Always ask for advice opinion if you're unsure of your suggestions. The just go ahead do it philosophy that some advocate just puts errors into OSM that may not get fully removed, especially if they've been around for a while have been copied by others. Technically they aren't errors, just inconsistent data that isn't useful for anything unless someone cleans it up first, which takes a lot more effort that could have been avoided in the first place with a little planning. That's assuming you don't get people using the same/similar tags to mean different things of course, in which case you would have to manually clean up the data since a computer most likely wouldn't understand the context nor how to express it to a human. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
-Message d'origine- De : Joseph Reeves [mailto:iknowjos...@gmail.com] Envoyé : mercredi 14 octobre 2009 00:07 À : Morten Kjeldgaard Cc : Gilles Corlobé; talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) To be honest I don't see the point. You should use the already existing landuse=military. School, parking lot, etc. that you mentioned should be rendered on top of that, like landuse=residential. Using landuse also avoids certain ambiguities like: which side of the boundary is the military area? +1 Perhaps also use a relation to tie various landuses together into a military-base=name group or something similar. If the OP doesn't like how nested landuse is rendered in a specific renderer should they not file a bug with the maintainers of that renderer? Seems better than adding to the db. Joseph In my opinion, the tag landuse=military should only be used for specificly military activities, like those discribed in the wiki. Some of you have suggested to create 2 areas, covering the same place. I don't think this is correct. One of you said that's done every day. How can it be? There can't be a forest inside a residential area. The residential area stops where begins the forest (and the contrary). Gilles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/14 Gilles Corlobé gil...@corlobe.tk: In my opinion, the tag landuse=military should only be used for specificly military activities, like those discribed in the wiki. Some of you have suggested to create 2 areas, covering the same place. I don't think this is correct. One of you said that's done every day. How can it be? There can't be a forest inside a residential area. The residential area stops where begins the forest (and the contrary). The military have a training area near here: http://osm.org/go/ueWPq0J imho it should have 2 areas, one for the military training area and one for the natural=wood that makes up the majority of the area: http://maps.google.com.au/?ie=UTF8ll=-25.92146,152.938957spn=0.058514,0.111494t=hz=14 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
-Message d'origine- De : John Smith [mailto:deltafoxtrot...@gmail.com] Envoyé : mercredi 14 octobre 2009 06:55 À : Gilles Corlobé Cc : talk@openstreetmap.org Objet : Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military) 2009/10/14 Gilles Corlobé gil...@corlobe.tk: In my opinion, the tag landuse=military should only be used for specificly military activities, like those discribed in the wiki. Some of you have suggested to create 2 areas, covering the same place. I don't think this is correct. One of you said that's done every day. How can it be? There can't be a forest inside a residential area. The residential area stops where begins the forest (and the contrary). The military have a training area near here: http://osm.org/go/ueWPq0J imho it should have 2 areas, one for the military training area and one for the natural=wood that makes up the majority of the area: http://maps.google.com.au/?ie=UTF8ll=- 25.92146,152.938957spn=0.058514,0.111494t=hz=14 You're right : If the area is covered by a forest (or a lake, or whatever), it should appear like this on the map. What would a user think if he finds a forest (even if it's in a military area) that is not on the map? And we should remerber that all users are not forbiden to enter into military areas! Some users needs to know the exact nature of the area (to know the size of a forest for example). Gilles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/14 Gilles Corlobé gil...@corlobe.tk: You're right : If the area is covered by a forest (or a lake, or whatever), it should appear like this on the map. What would a user think if he finds a forest (even if it's in a military area) that is not on the map? And we should remerber that all users are not forbiden to enter into military areas! Some users needs to know the exact nature of the area (to know the size of a forest for example). I was just pointing out that there is a good reason to have 2 similar/same areas due to different land uses of the same land. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Bekijk mijn foto's op Facebook
Hoi talk-nl@openstreetmap.org, Ik heb een Facebookprofiel gemaakt waar ik mijn foto's, video's en evenementen kan plaatsen en ik wil jou als vriend toevoegen zodat je het kan zien. Eerst moet je lid worden van Facebook! Als je lid wordt, kan je ook je eigen profiel maken. Bedankt, Joris Klik op de volgende link om te registreren voor Facebook: http://www.facebook.com/p.php?i=10377197097k=Z6E3Y5T3R6W16KCJPBV3Y4QZRQIB4XZ1RSGWCr Already have an account? Add this email address to your account http://www.facebook.com/n/?merge_accounts.phpi=10377197097k=z6e3y5t3r6w16kcjpbv3y4qzrqib4xz1rsgwc.talk...@openstreetmap.org is uitgenodigd voor Facebook door Joris Meijerink. Als je dergelijke e-mails van Facebook in de toekomst niet meer wilt ontvangen, klik je op onderstaande link om je uit te schrijven. http://www.facebook.com/o.php?k=d4a890u=1090890914mid=13ee446G4105aca2G0G8 Het Facebook-kantoor bevindt zich op de volgende locatie: 1601 S. California Ave., Palo Alto, CA 94304. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Get DCDB QLD Lite running on Mapserver on Windows.
Hi, I just got the DCDB QLD Lite data running on my windows machine. (I don't have a spare box for Linux and wouldn't have a clue how to get that all going etc). Should I post up what I did? I should warn that I'm a complete noobie and have no idea if I did it right or not. But, I can read, Google info and copy and paste. It's surprising how far that will get you, lol. As a summary this is kinda what happened to my computer over the last few days: Installed mapserver and some demos. Edited gmap demo to get it working thus verifying mapserver worked on windows. Downloaded the DCDB QLD Lite data. Setup a map file for the data. Got frustrated at it not working until I renamed the data files. Realised that the data was just t big as it ran like a sloth. Installed PostgreSQL/Postgis. Converted the data it all works locally nice and fast. I'll post more details if I'm allowed (just asking before I post something a few pages long). Cheers, Brentyn. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] navit files
navit files built form osm data don't show a road if there is a reuse of the admin boundary for the road and so navigation around adelaide is going to be really interesting as a lot of main roads have just disappeared please guys don't reuse admin boundaries ( like ABS ) to replace perfectly good data that was already in the database. Just like i used to reuse the post office node for the place name and then the rendering rules changed for mapnik and none of those named places showed up on the map. :( ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] navit files
2009/10/13 Liz ed...@billiau.net: navit files built form osm data don't show a road if there is a reuse of the admin boundary for the road and so navigation around adelaide is going to be really interesting as a lot of main roads have just disappeared please guys don't reuse admin boundaries ( like ABS ) to replace perfectly good data that was already in the database. This is really a bug in their software, specifically the osm2navit binary, it would be better to file a bug and get them to fix the issue rather than trying to work around their bugs. Have you filed a bug report for this at all? Just like i used to reuse the post office node for the place name and then the rendering rules changed for mapnik and none of those named places showed up on the map. Did you file a bug report against mapnik for this? There is no reason a single node can't be used for both. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] navit files
2009/10/13 Elizabeth Dodd ed...@billiau.net: On Tue, 13 Oct 2009, John Smith wrote: This is really a bug in their software, specifically the osm2navit binary, it would be better to file a bug and get them to fix the issue rather than trying to work around their bugs. Have you filed a bug report for this at all? I've sat on irc for nearly a week waiting for some action to discuss it their irc channel first as i also wanted to talk about the strange computed routes i was getting Pretty sure I had the same issue when I tried to report their routing engine was screwy too. Alternatively there is plan B, there is a number of people on this list that can code, and even more on the dev list, I'm sure between us we can cook up a suitable patch. Is anyone familiar with the osm2navit code at all? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Get DCDB QLD Lite running on Mapserver on Windows.
On Tue, Oct 13, 2009 at 6:43 PM, Liz ed...@billiau.net wrote: On Tue, 13 Oct 2009, Lindley Bowers wrote: On Tue, Oct 13, 2009 at 6:19 PM, John Smith deltafoxtrot...@gmail.comwrote: 2009/10/13 Lindley Bowers lindleybow...@gmail.com: I'll post more details if I'm allowed (just asking before I post something a few pages long). Might be better to do this as a wiki page... Um, I don't know how to do a wiki page. But I can read, copy/paste, so I'll see what happens :). Looks like a wiki page then. I have no idea as to the organization of the Wiki site. What should I call the page? Ugh, how do you create a new page? I'll do a bit of a run down on how I got the shape file data serving by mapserver from a PostgreSQL database in Windows. do you want someone to make a basic page and you put some text into it? Yes please. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Update for bigtincan tile database.
I've just updated the update process for the map server, the previous minutely files produced from the OSM DB had a serious flaw where long updates would be missed which would require the entire DB to be reloaded periodically, however now better changesets are produced which includes changes made since the last change set, but may not be produced each minute. Hopefully now there will be less missing data from the database and will eliminate the need to reload the entire database of information. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] navit files
I've been looking over the navit code and have made some minor tweaks to suite me. My first guess is that the issue might be able to be worked around by changing the order that osm2navit looks at properties - e.g making ti look at decide these are roads instead of boundaries. Of course this will mean boundaries will disappear in those places. Solving it properly will probably be trickier. I'll have a look at it on the weekend. cheers On Tue, Oct 13, 2009 at 7:25 PM, John Smith deltafoxtrot...@gmail.comwrote: 2009/10/13 Elizabeth Dodd ed...@billiau.net: On Tue, 13 Oct 2009, John Smith wrote: This is really a bug in their software, specifically the osm2navit binary, it would be better to file a bug and get them to fix the issue rather than trying to work around their bugs. Have you filed a bug report for this at all? I've sat on irc for nearly a week waiting for some action to discuss it their irc channel first as i also wanted to talk about the strange computed routes i was getting Pretty sure I had the same issue when I tried to report their routing engine was screwy too. Alternatively there is plan B, there is a number of people on this list that can code, and even more on the dev list, I'm sure between us we can cook up a suitable patch. Is anyone familiar with the osm2navit code at all? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] navit files
John Smith deltafoxtrot...@gmail.com wrote: Pretty sure I had the same issue when I tried to report their routing engine was screwy too. The idlers and lurkers will read the backlog when they return. Conversations can go very slowly this way, but communication is possible. Bug tracker: http://trac.navit-project.org/ Forums (no idea how closely they're monitored): http://sourceforge.net/projects/navit/forums There doesn't appear to be a mailing list. Alternatively there is plan B, there is a number of people on this list that can code, and even more on the dev list, I'm sure between us we can cook up a suitable patch. Is anyone familiar with the osm2navit code at all? I've looked it over a few times and even modified it a little. It's 5500 lines of dense code with lots of global variables, nearly no comments and a highly abstracted attribute-driven metaschema so I'll make no claims of familiarity. -- Sam Couter | mailto:s...@couter.id.au OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] navit files
2009/10/13 Franc Carter franc.car...@gmail.com: I've been looking over the navit code and have made some minor tweaks to suite me. My first guess is that the issue might be able to be worked around by changing the order that osm2navit looks at properties - e.g making ti look at decide these are roads instead of boundaries. Of course this will mean boundaries will disappear in those places. I wonder if it's possible to duplicate the object to break it up into 2 objects instead of one, and strip appropriate tags from the respective objects. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Get DCDB QLD Lite running on Mapserver on Windows.
Thanks for the page you made on the wiki Liz :). I've had a stab at putting a guide up of what I did and it is at: http://wiki.openstreetmap.org/wiki/QueenslandDcdbLite On Tue, Oct 13, 2009 at 11:25 PM, morb@beagle.com.au wrote: Quoting Lindley Bowers lindleybow...@gmail.com: Hi, I just got the DCDB QLD Lite data running on my windows machine. (I don't have a spare box for Linux and wouldn't have a clue how to get that all going etc). Should I post up what I did? I should warn that I'm a complete noobie and have no idea if I did it right or not. But, I can read, Google info and copy and paste. It's surprising how far that will get you, lol. If you were having fun then fine. But you can compare your notes to mine: Yes I was :), even if I got a bit frustrated with mapserver until I figured out that it doesn't like long names for files. http://wiki.openstreetmap.org/wiki/User:Morb_au I suppose I should split it off to another page. Realised that the data was just t big as it ran like a sloth. Installed PostgreSQL/Postgis. Yes, that size shapefile (even with a so called spatial index) didn't seem to return anything under 30 seconds I was getting 5 or 6 tiles a minute into JOSM but it was still incredibly slow. Cheers, Brentyn. What's with people starting with Bren starting their own DCDB servers? That's 3 now (-: Brendan ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
Unless anyone has an objection I propose that we tagged non-existent roads from DCDB Qld as: highway=gazetted_road Anything that hasn't been surveyed can be tagged as highway=road which is consistent with current usage, these will also be rendered enough to indicate they need to be surveyed and hopefully this will encourage people to participate even if they don't have a GPS. I updated the wiki as well to reflect this: http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#What_about_using_meta_information_from_the_DCDB_Qld_date.3F ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Get DCDB QLD Lite running on Mapserver on Windows.
On Wed, 14 Oct 2009, morb@beagle.com.au wrote: If you were having fun then fine. But you can compare your notes to mine: http://wiki.openstreetmap.org/wiki/User:Morb_au I suppose I should split it off to another page. I made the page http://wiki.openstreetmap.org/wiki/QueenslandDcdbLite with the intention that it could have different solutions on it, or links to other solutions ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
Thinking about it now, I realise you are quite correct :) My apologies. - Ben. 2009/10/14 Liz ed...@billiau.net On Wed, 14 Oct 2009, Ben Kelley wrote: I would have thought highway=unclassified would be better if you don't know what type of highway it is. the highway=road has actually the exact use (in the wiki) that John mentioned. highway=unclassified has a use which isn't i don't know, it means it's a lowly road which doesn't have a MABC type (in UK, to be precise) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
2009/10/14 Sam Vekemans acrosscanadatra...@gmail.com: Ok, so my big question is: Why are your property boundaries rendered with solid fill? Its not indicating land use, and should be rendered as a 'dash-dot-dot-dash' line. (at least thats how i remember it from drafting class) So if the property boundaries arnt filled in, then there is room to go around and tag areas of 'landuse=residential; or farmland or protected_area or industrial or what ever. Its after the area has been tagged with an appropriate landuse tag, that it becomes clear where the roads 'should technically' be, and there is also (I think) a tag landuse=civil (to show that the city owns it) Me hopes that makes sence :) It makes sense, but you missed the point entirely. The property boundary landuse is unknown, between the boundaries there are voids, these voids seem to exist where there is road ways and water ways. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] [OSM-talk] [tagging] Feature Proposal - RFC - (boundary=military)
2009/10/14 Liz ed...@billiau.net: On Wed, 14 Oct 2009, Shaun McDonald wrote: Before you propose a tag, you should be using it. how ridiculous prohibiting discussion before polluting the data base with even more tags There seems to be 2 completely distinct camps within OSM. Those that think any tag you can think of should be used and who cares if the data is completely useless for anything later as long as it's human readable and verifiable. Those that want to put some thought into how to make the data as useful as possible for all purposes by trying to achieve some kind of consensus before tagging. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
2009/10/14 Sam Vekemans acrosscanadatra...@gmail.com: But of course the landuse us 'unknown' by default. .. so what needs to be done is to go around and find out what the actual landuse is. ... of course there are voids there are voids all over the map of black space. :) Swing and a miss... The property boundary data looks like this: http://wiki.openstreetmap.org/images/0/0d/Mapserv-wms-example.all-hallows.png The thickish white sections are actually transparent pixels because there is no data in this data set for that area, the most common things that fill the void that I've see so far is road ways and water ways. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
I made another example: http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png It's clearer in this screen shot (using JOSM, JOSM has a black background so the transparent pixels are black) exactly what runs down the middle of these voids. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
2009/10/14 John Smith deltafoxtrot...@gmail.com: http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png Here's the after shot: http://wiki.openstreetmap.org/images/b/bf/Dcdb-example2.png ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to tag a non-existent road
Then the yellow must be all the landuse=residential then :) As land use can extend past the property boundary, were there is an easment. Strike 3, im out. Since were on the tagging list, the sidewalks waterworks like sewer lines, or underground cable lines, do we map these too, as the data is also available? Sam On 10/13/09, John Smith deltafoxtrot...@gmail.com wrote: I made another example: http://wiki.openstreetmap.org/images/5/5d/Dcdb-example.png It's clearer in this screen shot (using JOSM, JOSM has a black background so the transparent pixels are black) exactly what runs down the middle of these voids. -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] Excelente artigo da Wired
Comentando as recentes mudanças no Google Maps e como o modelo do OSM é melhor (em inglês) http://www.webmonkey.com/blog/Google_Maps_Adds_More_Detail__Takes_a_Cue_From_OpenStreetMap []s ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excelente artigo da Wired
Bem bacana. Li o artigo, e fui lendo artigos relacionados, como diz a minha namorada boiando na internet até chegar nesse site: http://tiledrawer.com/ Ô, assim que tiver um tempinho vou passar a renderizar as linhas de ônibus daqui do Rio... [] 2009/10/13 Junior, Claudomiro claudomiro.jun...@citi.com Comentando as recentes mudanças no Google Maps e como o modelo do OSM é melhor (em inglês) http://www.webmonkey.com/blog/Google_Maps_Adds_More_Detail__Takes_a_Cue_From_OpenStreetMap []s ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Arlindo Saraiva Pereira Jr. Bacharelando em Sistemas de Informação - UNIRIO - uniriotec.br Consultor de Software Livre da Uniriotec Consultoria - uniriotec.com Acadêmico: arlindo.pere...@uniriotec.br Profissional: arlindo.pere...@uniriotec.com Geral: cont...@arlindopereira.com Tel.: +5521 92504072 Jabber/Google Talk: nig...@nighto.net Skype: nighto_sumomo Chave pública: BD065DEC ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Transporte público no OSM
Olá de novo, que bom saber que tem mais gente aqui que se interessa em criar informações de transportes no OSM! Acho que já somos um número suficiente para começarmos a nos organizar e vejo com muito bons olhos a ideia de termos o nosso Öpnvkarte também! Algumas coisas: 1) Página no Wiki O que acham de começarmos criando uma página no Wiki do OSM para tentarmos centralizar as recomendações de como adicionar informações sobre transportes públicos ao OSM? Algo como http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Transporte_Público. 2) Marcação das paradas de ônibus no OSM Na página do Wiki do OSM sobre transporte público, acho que o principal ponto de discórdia é sobre onde marcar as paradas de ônibus, como um node na pista ou logo na lateral. O Wiki recomenda na lateral, mas tem uma discussão sobre a marcação das paradas na via em si ser melhor para fins de construir aplicações de planejamento de rotas. A discussão ainda está em andamento, e está bem confuso entender o que está sendo feito. De qualquer maneira, as páginas com as discussões mais recentes parecem ser estas (são a elas que as mensagens da talk-transit se referem no final de setembro/2009): http://wiki.openstreetmap.org/wiki/Transit http://wiki.openstreetmap.org/wiki/Buses http://wiki.openstreetmap.org/wiki/User:PeterIto/Stop_Place Apesar de ainda ser uma proposta, creio que o último link é o que apresenta a solução mais bem pensada, e penso que poderíamos recomendar que essa seja a solução adotada no Brasil. Se entendi corretamente, a ideia é que, no caso de paradas de ônibus simples, seja usado highway=stopping_point na via, highway=bus_stop no local onde os passageiros esperam, e uma relation to tipo site=bus_stop para conectar uma à outra. Confere? Acham que é uma solução viável? 3) Quantidade de informações sobre transporte público a ser incluída no OSM Me cadastrei na lista talk-transit que o Vitor sugeriu (obrigada pela dica!) e dei uma lida rápida num tópico recente e bem interessante, em especial essa mensagem aqui: http://lists.openstreetmap.org/pipermail/talk-transit/2009-September/000618.html. O autor discute sobre qual seria o nível de detalhe que queremos disponibilizar no OSM: A) apenas as paradas e estações, mas sem as rotas; B) a estrutura física e as rotas de ônibus; ou C) a estrutura física, as rotas e os horários. Veja que isso se refere apenas às informações que estariam no OSM em si; nada impede que nas opções A e B as informações de rotas e de horários sejam servidas por outro serviço construído em cima dos dados do OSM (OpenTransitMap? :) ). Eu, pessoalmente, acredito que o ponto A que ele citou seria o mais adequado para nós no Brasil. Não sei como é em Natal ou no Rio, mas em Brasília é uma coisa de louco. Temos por volta de mil linhas de ônibus [1], sem exageros. Uma aberração criada pela falta de planejamento e de integração tarifária, que, espero, vai ser corrigida cedo ou tarde. Como um mapa de visualização dessas rotas iria aparecer, eu não sei... Talvez algo não muito útil para quem quer informações sobre os ônibus. Imagino que seria muito mais fácil ter as informações de rotas específicas, em resultados de buscas feitas pelo usuário, mostradas como uma camada em cima de um mapa. Mas o principal motivo que eu acho que a definição das rotas de ônibus diretamente no OSM é dispensável é porque estou pensando na criação de um sistema de informação de itinerários de transporte público como aquele exemplo que eu dei (hbus.ca), que usa o GTFS [2] como formato para especificar a informação relativa às rotas e aos horários. O GTFS já está virando um de facto standard para aplicações desse tipo. E o negócio é que a informação sobre as rotas já existe num feed GTFS, como um conjunto de paradas de ônibus em uma determinada ordem. As paradas de ônibus são identificadas por meio de latitude e longitude e por um identificador único, e podem também ter um nome por extenso. Usando um identificador único no GTFS que seja relacionado com um identificador único na tag que identifica a parada no GTFS fica fácil fazer a ligação entre uma coisa e outra. Além do problema dessa redundância, tem também o de atualizar as informações das linhas. Acredito que seria mais efetivo fazer atualizações sobre as linhas em um arquivo GTFS do que no OSM. 4) Ainda sobre as paradas, acho que seria interessante também pensarmos numa maneira de identificar as paradas de ônibus de maneira única, para facilitar caso os dados sejam exportados para um arquivo GTFS, por exemplo. A primeira coisa que me vem à cabeça é incluir a sigla do estado + identificador para o município, seguido de uma sequência numérica única para o município (DF-0001-1?). Dessa forma de repente ficaria mais fácil evitar identificadores repetidos. Que acham? Faz sentido querer ter identificadores únicos? Alguma cidade do Brasil já adota um id único para as paradas de ônibus, vocês sabem? Bom, já falei demais para um email só :) Aguardo opiniões e críticas.
Re: [Talk-br] Transporte público no OSM
Oioi, 2009/10/13 Maira gro...@catdevrandom.com Olá de novo, que bom saber que tem mais gente aqui que se interessa em criar informações de transportes no OSM! Acho que já somos um número suficiente para começarmos a nos organizar e vejo com muito bons olhos a ideia de termos o nosso Öpnvkarte também! Algumas coisas: 1) Página no Wiki O que acham de começarmos criando uma página no Wiki do OSM para tentarmos centralizar as recomendações de como adicionar informações sobre transportes públicos ao OSM? Algo como http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Transporte_Públicohttp://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Transporte_P%C3%BAblico . Pode criar a página que eu ajudo a populá-la. 2) Marcação das paradas de ônibus no OSM Na página do Wiki do OSM sobre transporte público, acho que o principal ponto de discórdia é sobre onde marcar as paradas de ônibus, como um node na pista ou logo na lateral. O Wiki recomenda na lateral, mas tem uma discussão sobre a marcação das paradas na via em si ser melhor para fins de construir aplicações de planejamento de rotas. A discussão ainda está em andamento, e está bem confuso entender o que está sendo feito. De qualquer maneira, as páginas com as discussões mais recentes parecem ser estas (são a elas que as mensagens da talk-transit se referem no final de setembro/2009): http://wiki.openstreetmap.org/wiki/Transit http://wiki.openstreetmap.org/wiki/Buses http://wiki.openstreetmap.org/wiki/User:PeterIto/Stop_Place Apesar de ainda ser uma proposta, creio que o último link é o que apresenta a solução mais bem pensada, e penso que poderíamos recomendar que essa seja a solução adotada no Brasil. Se entendi corretamente, a ideia é que, no caso de paradas de ônibus simples, seja usado highway=stopping_point na via, highway=bus_stop no local onde os passageiros esperam, e uma relation to tipo site=bus_stop para conectar uma à outra. Confere? Acham que é uma solução viável? Pois é. Eu gosto da simplicidade do highway=bus_stop no node da via quando a via é de mão-única (maioria absoluta aqui no Rio) e do lado quando é de mão-dupla. Vou ler com calma a proposta antes de opinar sobre ela, depois mando outro email sobre. 3) Quantidade de informações sobre transporte público a ser incluída no OSM Me cadastrei na lista talk-transit que o Vitor sugeriu (obrigada pela dica!) e dei uma lida rápida num tópico recente e bem interessante, em especial essa mensagem aqui: http://lists.openstreetmap.org/pipermail/talk-transit/2009-September/000618.html . O autor discute sobre qual seria o nível de detalhe que queremos disponibilizar no OSM: A) apenas as paradas e estações, mas sem as rotas; B) a estrutura física e as rotas de ônibus; ou C) a estrutura física, as rotas e os horários. Veja que isso se refere apenas às informações que estariam no OSM em si; nada impede que nas opções A e B as informações de rotas e de horários sejam servidas por outro serviço construído em cima dos dados do OSM (OpenTransitMap? :) ). Eu, pessoalmente, acredito que o ponto A que ele citou seria o mais adequado para nós no Brasil. Não sei como é em Natal ou no Rio, mas em Brasília é uma coisa de louco. Temos por volta de mil linhas de ônibus [1], sem exageros. Uma aberração criada pela falta de planejamento e de integração tarifária, que, espero, vai ser corrigida cedo ou tarde. Como um mapa de visualização dessas rotas iria aparecer, eu não sei... Talvez algo não muito útil para quem quer informações sobre os ônibus. Imagino que seria muito mais fácil ter as informações de rotas específicas, em resultados de buscas feitas pelo usuário, mostradas como uma camada em cima de um mapa. Faz sentido. Aqui no Rio, também é assim. [3] Mas o principal motivo que eu acho que a definição das rotas de ônibus diretamente no OSM é dispensável é porque estou pensando na criação de um sistema de informação de itinerários de transporte público como aquele exemplo que eu dei (hbus.ca), que usa o GTFS [2] como formato para especificar a informação relativa às rotas e aos horários. O GTFS já está virando um de facto standard para aplicações desse tipo. E o negócio é que a informação sobre as rotas já existe num feed GTFS, como um conjunto de paradas de ônibus em uma determinada ordem. As paradas de ônibus são identificadas por meio de latitude e longitude e por um identificador único, e podem também ter um nome por extenso. Usando um identificador único no GTFS que seja relacionado com um identificador único na tag que identifica a parada no GTFS fica fácil fazer a ligação entre uma coisa e outra. Além do problema dessa redundância, tem também o de atualizar as informações das linhas. Acredito que seria mais efetivo fazer atualizações sobre as linhas em um arquivo GTFS do que no OSM. Pode ser, mas também não vejo problema em inserir os dados diretamente no OSM. Digo, eles não são renderizados por padrão, então seria o
Re: [Talk-br] Transporte público no OSM
Em Ter, 2009-10-13 às 22:43 +0300, Maira escreveu: Olá de novo, (...) 3) Quantidade de informações sobre transporte público a ser incluída no OSM Me cadastrei na lista talk-transit que o Vitor sugeriu (obrigada pela dica!) e dei uma lida rápida num tópico recente e bem interessante, em especial essa mensagem aqui: http://lists.openstreetmap.org/pipermail/talk-transit/2009-September/000618.html. O autor discute sobre qual seria o nível de detalhe que queremos disponibilizar no OSM: A) apenas as paradas e estações, mas sem as rotas; B) a estrutura física e as rotas de ônibus; ou C) a estrutura física, as rotas e os horários. Veja que isso se refere apenas às informações que estariam no OSM em si; nada impede que nas opções A e B as informações de rotas e de horários sejam servidas por outro serviço construído em cima dos dados do OSM (OpenTransitMap? :) ). Olá, Será viável incluir os horários também? Aqui na Grande BH isso muda muito, e provavelmente sem a ajuda direta de uma entidade de trânsito, ficaria difícil manter isso atualizado com uma pequena equipe de voluntários. Acho que ligar as rotas a outro serviço com os horários mais apropriado. 4) Ainda sobre as paradas, acho que seria interessante também pensarmos numa maneira de identificar as paradas de ônibus de maneira única, para facilitar caso os dados sejam exportados para um arquivo GTFS, por exemplo. A primeira coisa que me vem à cabeça é incluir a sigla do estado + identificador para o município, seguido de uma sequência numérica única para o município (DF-0001-1?). Dessa forma de repente ficaria mais fácil evitar identificadores repetidos. Que acham? Faz sentido querer ter identificadores únicos? Alguma cidade do Brasil já adota um id único para as paradas de ônibus, vocês sabem? Em Belo Horizonte os pontos tem um número (se não me engano de 4 algarismos) que identifica cada ponto de ônibus, com um nome de fácil identificação, como Praça da Liberdade - 1. Cada cidade tem uma entidade própria para cuidar desse tipo de detalhe (ao menos acho que deveria :)). Abraço, -- Samuel Vale srcv...@minaslivre.org signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] OSM case sensitiv?
Hallo. Am Montag, 12. Oktober 2009 schrieb Stephan Knauss: Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. Brauchen wir diese Freiheit wirklich? Ich bin dafür, dass jeder, der die Daten nutzt (und folglich weiß, ob er case-sensitive Infos erwartet) einfach ggf. ein lower() [je nach Sprache] aufruft. Das schränkt niemanden ein und löst das Problem auch. Es gibt sicherlich viele gute Gründe warum man das eine oder andere in den key packen will und technisch ist es kein Problem. Warum also irgendwas einschränken nur weil der Tellerrand des einzelnen vielleicht zu hoch ist? Gruß, Bernd -- Ein Huhn ist weiter nichts als die Methode eines Eis, ein weiteres Ei zu machen. 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-de] Strato sponsort 3 Server für OSM
Tirkon tirko...@yahoo.de wrote: OSM gestellt. Im konkreten Fall denke ich schon, dass sich so mancher fragt, warum der Aufbau einer Seite beim Navigieren in Potlatch mitunter Minuten dauert. Manchmal befördert dieses lange Andauern sogar den Firefox ins Jenseits. Vielleicht solltest Du Dir mal den josm anschaun. Und das nicht nur an meinem Computer und meinem DSL Anschluss. Mit den unteren 6 Netzwerklayern hat OSM eigentlich nichts am Hut. Wir bewegen uns auf Layer7, der Anwendungsebene. Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Original-Nachricht Datum: Mon, 12 Oct 2009 19:59:26 +0200 Von: Frederik Ramm frede...@remote.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strato sponsort 3 Server für OSM Ja. Erschwerend kommt hinzu, dass wir fuer sehr viele Anwendungen diese Informationen im topologisch sauberen OSM-Modell ausliefern wollen und *nicht* in Form von Standardgeometrien. Das heisst, wir wollen schoen ordentlich alle betroffenen Nodes, Ways und Relations haben und nicht einfach eine in die Landschaft gezeichnete Linie. Und warum sollen die klassischen Ansaetze nicht 'topologisch sauber' sein? Auf letzteres sind die einschlaegigen Geodatenbanken aber in der Regel spezialisiert. Und das hat auch seine technischen Gruende und Vorteile. In der API sieht eine typische gib mir alles in diesem Bereich-Anfrage so aus: 1. Suche alle Nodes in diesem Bereich. Geht schnell, kann aber schon mal einige zigtausend Nodes ergeben. 2. Suche alle Ways, in denen irgendwo einer von diesen Nodes vorkommt. Hier liegt die Krux, denn das ist sehr ineffizient. Polygone und Flaechen kann ich als Toplevel-Objekte ueber Bounding boxes sehr effizient verwalten und dann komme ich top down auch schnell an die verwendeten Nodes. Es braucht nur eine Abfrage, welches Rechteck (bounding box) sich mit anderen Rechtecken schneidet. Ich wuerde mich stark wundern, wenn die DB intern keine Bounding boxes (oder andere Tricks) zur internen Beschleunigung verwendet, denn sonst darf man fuer jede Abfrage immer alle Nodes in Betracht ziehen. Insgesamt ist das halt eine nicht ganz primitive Operation. Man bekommts hin, wenn man ein paar uebergeordnete Indices mitfuehrt, aber der wirkliche Vorteil erschliesst sich wohl nur wenigen. Klar ist ein Modell erst einmal komplexer, das zwischen Stuetzpunkten, POIs und Verbindungsknoten unterscheidet, aber im taeglichen Gebrauch werden schon Vorteile sichtbar. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Bernd Wurst wrote: Hallo. Am Montag, 12. Oktober 2009 schrieb Stephan Knauss: Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. Brauchen wir diese Freiheit wirklich? Ich bin dafür, dass jeder, der die Daten nutzt (und folglich weiß, ob er case-sensitive Infos erwartet) einfach ggf. ein lower() [je nach Sprache] aufruft. Das schränkt niemanden ein und löst das Problem auch. Dann stell mal dein locale auf Türkisch und versuch ein lower(I). Das Ergebnis ist dann nicht i sondern (soweit ich mich erinnere) ÿ. D.h. selbst wenn die Eingangsdaten nur reine 7bit ASCII Zeichen benutzen und keinerlei nationale Sonderzeichen ist nicht garantiert das das Ergebnis von lower() auch nur aus ASCII Zeichen besteht ... Case insensitive Benamsung in Zusammenhang mit Internationalisierung/ Lokalisierung geht wegen solcher nicht eindeutigen Groß/Klein Abbildungen immer irgendwann nach hinten los. PS: das hat damals einige Zeit gedauert im PHP Land bis mal irgendwem aufgefallen ist das die meisten der Die Image- Funktionen sind nicht verfügbar obwohl die entsprechende Extension geladen ist von türkischen Benutzern stammten und da ein kausaler Zusammenhang besteht ... PHP ist leider ein gutes Beispiel für die Fallstricke von Case Insensitve Identifiern im internationalen Umfeld. Mittlerweile benutzt die Zend Engine intern nur noch das US ASCII Mapping für Case Insesitive Vergleiche und wird damit für alle nationalen Sonderzeichen wieder Case Sensitive, was neben der eh schon inkonsistenten Funktionen sind case insensitve, Variablen case sensitive und Konstanten je nach Deklaration das eine oder das andere die Identifier Vergleichsregeln noch undurchschaubarer macht ... leider gibt es keine Möglichkeit das gerade zu ziehen und dabei gleichzeitig rückwärtskompatibel zu bleiben. Diese spezielle Büchse der Pandora lässt sich nun nicht mehr einfach schließen :( -- Hartmut Holzgraefe, MySQL Regional Support Manager, EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Am 13. Oktober 2009 02:01 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: dann schreibe ich hier halt doch nochmal was: aha? Du findest, das sieht so aus, als hätte jemand was aus dem Gebäude herausgenommen? Abgesehen davon, dass ich schon einen Unterschied sehe zwischen Erde und einem Gebäude, finde ich pers. auch nicht, dass es so aussieht. Ich finde es sieht so aus, als hätte jemand das Gebäude so gebaut, dass es einen Durchgang gibt. Wieder verkürzt. Das Gebäude wurde nicht über die Passage geplant, sondern als Quader und dann hat der Architekt ein Loch ins Modell gesägt und gesagt: Hier führt die Passage durch. wir wollen wohl das Tagging nicht vom Entwurfsprozess abhaengig machen, oder? Es ist zwar nicht ausgeschlossen, dass ein Architekt so arbeitet (subtraktiv), es kann aber genauso auch anders sein, und ist im Einzelfall sicher aufwendig zu ermitteln. Dasselbe Objekt (Ladenpassage) sollte m.E. unabhaengig vom Entwurfsprozess getaggt werden koennen. (allerdings ist das Teil z.B. ein Hindernis, das mal nicht so ohne weiteres queren kann, während ein Tunnel in Querrichtung normalerweise kein Hindernis darstellt. Guter Einwand! danke Aber auch wenn auf beiden Seiten Erde aufgeschüttet wird, so dass man über den Tunnel hinweg spazieren kann, liegt der Tunnel für mich gefühlt nicht unter der Erdoberfläche. m.E. schon. Wenn Erde druebergeschuettet wurde, ist es unter der Erde. Nach dt. Norm gilt das zwar erst ab 80 m Laenge, aber das wuerde ich auch im Zweifel nicht so streng sehen. Was ist eigentlich eine Unterführung für Dich? Laut Wikipedia zählen Unterführungen nicht zu den Tunnels.. gute Frage, i.d.R. wuerde ich dafuer Tunnel nehmen, vor allem wenn entsprechend lang, und sie sind ja auch unter der Erde. Hm, ja.. eine gedeckte Einfahrt zum Innenhof würde ich nicht Tunnel nennen.. Passagen aber irgendwie schon.. tunnel steht für mich sinnbildlich für es geht nur nach vorne oder hinten raus, links/rechts/oben ist's zu, darum würde ich solche Stellen auch allgemein mit tunnel=yes tagen. gerade Passagen haben doch meistens zig Moeglichkeiten, eben nicht nur nach vorne und hinten rauszukommen, sondern seitlich, oben und sonst in alle Richtungen in Laeden und Ausgaenge abzubiegen (und dann weiter ins Freie), sie weiten sich auf fuer Plaetze, etc. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Bernd Wurst wrote: Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. Brauchen wir diese Freiheit wirklich? Ich bin dafür, dass jeder, der die Daten nutzt (und folglich weiß, ob er case-sensitive Infos erwartet) einfach ggf. ein lower() [je nach Sprache] aufruft. Das schränkt niemanden ein und löst das Problem auch. Du entwickelst keine Software, oder? Das Problem ist, dass die Schnittstellen definiert sein müssen, bzw. das genaue Format der Daten. Die Semantik muss klar sein. Beispiel: Wenn ein Programm building=yes verarbeiten kann, dann kann nicht einfach ein Building=yes gleich behandelt werden. Das Programm (bzw. der Autor) kann nicht wissen was Building bedeutet. Es könnte sein, dass dieser Key dazu verwendet wird um öffentliche Gebäude zu kennzeichnen, damit diese in einer Spezialkarte farblich anders gezeigt werden. Wenn Building bekannt ist, dass es eine andere Bedeutung hat als building, das der Autor weiß und es nur gleich behandeln will, dann wird er auch genau nach diesen beiden Strings suchen. Es könnte ja mal jemand auf die Idee kommen den Key BUilding zu erfinden, der dann noch eine ganz andere Bedeutung hat. Ein Lösungsvorschlag war so eine Art Alias-Tabelle. Meine Idee wäre es Namespaces einzuführen. Diese können einen Satz von Schlüsselwörtern definieren denen auch eine eindeutige Bedeutung zugeordnet werden kann. Das würde auch die MapFeatures-Problematik beenden. Alle die einen Starken Führer wollen einigen sich auf einen Namespace der von diesem spezifiziert wird, andere verwenden einen Namespace dessen Bedeutung sie in demokratischen Gremien definieren. Und andere verwenden einfach keinen Namespace weil es ihnen nicht frei genug ist. Die API müsste dazu jedem Element einen/mehrere Namespace(-Identifier) zuordnen können. Auf Tag-Ebene könnte das ein weiteres Attribut sein (n für namespace). Ein Node könnte dann solche tags haben tag n=osmf-namespace k=name v=eine Bedeutung für name / tag n=fossgis-namespace k=name v=andere Bedeutung für name / tag n=incubation k=neuerKey v=exotischer Schlüssel / Editoren/Renderer blenden die Namespaces aus, die sie nicht anzeigen/editieren wollen, bzw. wählen die Namespaces deren Semantik sie kennen. Ein Renderer mit der Intelligenz eines HAL 9000 kann auch einfach alles nehmen und erkennen was der Nutzer gemeint hat als er einen neuen Key erfunden hat ;) Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Hallo. Am Dienstag, 13. Oktober 2009 schrieb Stephan Knauss: Wenn ein Programm building=yes verarbeiten kann, dann kann nicht einfach ein Building=yes gleich behandelt werden. Das Programm (bzw. der Autor) kann nicht wissen was Building bedeutet. Es könnte sein, dass dieser Key dazu verwendet wird um öffentliche Gebäude zu kennzeichnen, damit diese in einer Spezialkarte farblich anders gezeigt werden. Man könnte auch einen Way einzeichnen und damit einen Node meinen. Ich würde sagen du machst dir mit dieser Meinung das Leben unnötig schwer. Großschreibung bei diesen allgemein bekannten Tags sind (meine Schätzung) zu 99,9% unerfahrene User die ohne Nachzudenken beim Tippen den ersten Buchstaben groß machen. Diese von mir gemeinten Tags bestehen zu 100% aus us-ascii-Zeichen, die mit einer us-ascii-locale in Kleinbuchstaben konvertiert werden können. Großschreibung deshalb für alles und jede Verwendung gleich abzuschaffen ist trotzdem zu viel des Guten, eben weil die Konversion eine triviale ist und man nichts einschränken muss um dasselbe Ergebnis zu bekommen. Gruß, Bernd -- Geld verdirbt nicht den Charakter eines Menschen, es entlarvt ihn! - Max Frisch 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
[Talk-de] Darstellung von Gebäuden
Bisher hatte ich immer ganz stolz auf unsere Detailtreue verwiesen: http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=10.00601lat=53.5557zoom=15 Aber das finde ich noch genauer: http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=10.00134lat=53.55162zoom=17 Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Hallo Chris, sehe ich das richtig dass OSM generell case sensitiv ist, sowohl für Tags als auch für Werte ? Ja und nein. Grundsätzlich speichert OSM die Daten so, wie Du sie eingibst (also mit entsprechender Gross-Klein-Schreibung). Also oneway=yes ist was anderes als Oneway=yes und oneway=YES, etc. ? Hier ist der Fall insofern klar, als dass alle vom Sinn her gleichbedeutend sind. Empfolen (und am häufigsten verwendet) wird die Kleinschreibung. AFAIK verstehen die Routing-Programm aber alle Kombinationen von Gross- und Kleinschreibung. Ich stolpere nämlich gerade über die verschiedenen Schreibweisen von maxspeed=DE:urban (de:urban, DE:Urban, De:urban, De:Urban)... Etwas komplizierter, da es die von Tobias erwähnte Konvention gibt Länder gross und Sprachen klein zu schreiben. In den allermeisten Fällen gibt es keine Überschneidung, d. h. de:* und DE:* werden (fast) nie* gleichzeitig benutzt und es ist aus dem Schlüssel klar, ob Deutschland oder deutschsprachig gemeint ist. Um den Auswertern aber das Leben nicht unnötig kompliziert zu machen, sollte man sich an die Konventionen halten. Gruss, Thomas * Kennt jemand ein Beispiel, wo Sprach- und Landesabkürzung gleich- zeitig benutzt werden? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
