Re: [Talk-hr] Strah
On Tue, May 29, 2012 at 11:56:09AM +0200, Gordan Krešić wrote: Za ako tko ne prati Slashdot: http://www.tomtom.com/en_gb/licensing/newsletter/201205/didyouknow/ First they ignore you, then they ridicule you, then they fight you, then you win. znaci pred samim ciljem smo :-) A kada smo već tu: Navit, OsmAnd ili nešto treće za cestovnu navigaciju? A na kojoj platformi? Dosad sam trosio GpsMid, a skoro cu valjda vidjeti kako OsmAnd radi... -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Strah
On 06/29/2012 11:32 AM, Matija Nalis wrote: A na kojoj platformi? Dosad sam trosio GpsMid, a skoro cu valjda vidjeti kako OsmAnd radi... Taman nekidan izasla osmand 0.8 verzija, kazu da je dosta naprednija, i da ima pojacani offline ruting. nisam jos isprobao jer sam ju tek stavio(nightly build) ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Strah
osmand 0.8 verzija više nema mogućnost dodavanja openstreetbugs točki :( Dana 29. lipnja 2012. 11:51 hbogner hbog...@gmail.com je napisao/la: On 06/29/2012 11:32 AM, Matija Nalis wrote: A na kojoj platformi? Dosad sam trosio GpsMid, a skoro cu valjda vidjeti kako OsmAnd radi... Taman nekidan izasla osmand 0.8 verzija, kazu da je dosta naprednija, i da ima pojacani offline ruting. nisam jos isprobao jer sam ju tek stavio(nightly build) __**_ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-hrhttp://lists.openstreetmap.org/listinfo/talk-hr -- Svega što vrijedi Bog je stvorio malo, kako zlata tako i Hrvata. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Mapfactor Navigator
On Wed, Jun 13, 2012 at 11:09:20AM +0200, valent.turko...@gmail.com wrote: Najbojli je definitivno subjektivan pojam, ali evo zašto je meni Mapfactor Navigator bolji od Osmand-a nakon što sam ga koristio od Osijeka do Ohrida u Makediniji - korisničko sučelje je prvi faktor. Osmand je nepregledan, teško se snaći u izbornicima i nepotrebni koraci se teško izgjegavaju. UI na MF Navigatoru je ispeglano do savršenstva iako je Beta aplikacija. Mnoge komercijalne aplikacije bi imale što naučiti od MF Navogator UI designera. Pa daj primjer sto ti je specificno lose rijeseno u OSMAndu? Ne znam o kakvim kompliciranim izbornicima govoris (i zasto bi uopce lutao po izbornicima)? Meni treba Main/Search (ili Main/Favorites) i (ponekad) Menu/Define View i to je to sto sam trebao po menuima IKAD nakon pocetne instalacije aplikacije - i to u dva brza i jasno vidljiva klika sam tamo. Sto drugo ti koristis u Osmandu redovito da ti je komplicirano u menijima? Sve ostalo je long press na lokaciju na ekranu i odabir direktno iz jednog menija. Dakle na dva klika je prakticki vecina toga sto ti treba - jedan za lokaciju i jedan za akciju. Ne vidim kako bi moglo biti jednostavnije? Jedan killer feature koji fali Osmandu (i svim drugim OSM aplikacijama koje sam testirao) je routring putem pomoćne lokacije, za sada je MF Navigator jedina aplikacija koja ima ovaj feature. Nemam pojma. Ja kada putujem vani na duze i zelim obici x mjesta, kreiram si doma GPX za to (sa waypointima), pa onda imam route by GPX. Ako putem saznam nesto interesantno, onda lupim route to do tamo, pa nakon toga se vratim na route by GPX. Ono sto bi mi bilo *beskonacno* korisnije (a cega jos nema u OSMAndu AFAICT), je block this road for xxx meters (kada naletis na lose ucrtanu cestu/smjer ili radove na cesti ili prometnu nesrecu ili sl) pa da rekalkulira routu po tome. Jednostavno dodavanje Favorite lokacija, te jednostavno biranje da li je neka od postojećih waypoint, destination ili nešto treće. A u OSMAndu je to komplicirano? Long klik na ekran gdje ga zelis dodati, pa odabir iz menija da li zelis dodati kao finalnu desticiju, routati do/od tamo, dodati u favorite, kreirati GPX waypoint, uploadati POI ili otvoriti OSM bug. Kako je to rijeseno u toj tvojoj non-free aplikaciji a da je znacajno bolje? Vozio sam se kroz Hrvatsku, Srbiju (Niš, Šid, Beograd) i Makedoniju (Ohrid, Skopje, Struga), te su ulice bile dobro označene i nisam primjetio da su falile POI (benzinske i kafići), nisam ih tražio po imenu pošto sam u stranome gradu pa nisam niti znao imena, no pretraga po imenu POI-a je svakako feature koji treba dodati. Samo da bude jasno, Osmand podržavam jer je pod GPL licencom, i kupio sam Osmand+ da ih podržim no ipak aplikaciju nisam na putu koristio zbog jednostavnog razloga što sam našao bolju. A svakome prema izboru... Ali JA ako se vec furam na neki OSM, na neku otvorenost i suradnju i njihove prednosti, onda mi ne pada na pamet koristiti zatvorene aplikacije koje aktivno rade protiv toga -- pogotovo ako imam sasvim pristojnu alternativu. Ja recimo prvo gledam koja je licenca aplikacije prije nego uopce krenem razmatrati da li bi mi mogla biti interesantna. Radije platim nekom developeru 10x vise para da se nesto sto mi fali implementira u OSMAndu (ili implementiram sam - ali je*ala ih java ;) i bude dostupno svima, nego da kupim (ili skinem bez placanja, whatever) zatvorenu aplikaciju. Ili da parafraziram: besplatna neslobodna aplikacija je besplatna samo ako si spreman prodati svoju dusu vragu za 0kn :-) A da mi je bitna samo just works funkcionalnost a ne tamo neka suradnja, pomaganje drustvu, otvorenost podataka i aplikacija i slicne stvari, trosio bih neko non-free rjesenje. Vidis u drugim threadovima da ne bih padao s mostova i utapao se da koristim profesionalni TomTom ;) Koji IIRC ima block this road i (jos uvijek AFAICT) kvalitetnije rjesene obvezne smjerove ulica. -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Naselja u RH
On Fri, Jun 22, 2012 at 11:32:47AM +0200, hbogner wrote: Naravno da treba sa skriptom, ali tko će se toga uhvatiti? Hoćeš ti? Samo 100 linija koda :D pa mogu ja, trebao bih slijedeci tjedan imati nesto slobodnog vremena. Ideja za realizaciju, pa komentirajte: 1) izvuci sve nodeove koji imaju place=* iz RH OSM extracta. 2) izvuci sva mjesta iz DZS .xlsa i Ukupan broj stanovnika od tamo. 3) generirati .osm sa modify akcijama za sve sto je matchani place name (dodati population= i census=2011-preliminary i source=dzs.hr) 4) ispisati koja mjesta nema u OSM-u, te koja ima u OSM-u a nema u DZS-u 5) rucno popraviti/dodati podatke iz 4, pa ponoviti sve od 1 6) kada smo zadovoljni, finalni .osm ucitati u JOSM, pregledati jos jednom, i uploadati. 7) uploadati scriptu negdje da imamo za slijedeci puta cini li vam se ok? Ja napravim sve osim tocke 5, tu bi mi dobro dosla pomoc jer toliko vremena ipak necu uhvatiti bojim se... Ima li dobrovoljaca za pomoc oko tocke 5? -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Naselja u RH
Suzper, samo mala opaska na: source=dzs.hr treba biti ili source:population=dzs.hr ili population:source=dzs.hr treba pogledat na wiki, nisam siguran On 06/29/2012 01:33 PM, Matija Nalis wrote: On Fri, Jun 22, 2012 at 11:32:47AM +0200, hbogner wrote: Naravno da treba sa skriptom, ali tko će se toga uhvatiti? Hoćeš ti? Samo 100 linija koda :D pa mogu ja, trebao bih slijedeci tjedan imati nesto slobodnog vremena. Ideja za realizaciju, pa komentirajte: 1) izvuci sve nodeove koji imaju place=* iz RH OSM extracta. 2) izvuci sva mjesta iz DZS .xlsa i Ukupan broj stanovnika od tamo. 3) generirati .osm sa modify akcijama za sve sto je matchani place name (dodati population= i census=2011-preliminary i source=dzs.hr) 4) ispisati koja mjesta nema u OSM-u, te koja ima u OSM-u a nema u DZS-u 5) rucno popraviti/dodati podatke iz 4, pa ponoviti sve od 1 6) kada smo zadovoljni, finalni .osm ucitati u JOSM, pregledati jos jednom, i uploadati. 7) uploadati scriptu negdje da imamo za slijedeci puta cini li vam se ok? Ja napravim sve osim tocke 5, tu bi mi dobro dosla pomoc jer toliko vremena ipak necu uhvatiti bojim se... Ima li dobrovoljaca za pomoc oko tocke 5? ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Naselja u RH
Dana 29. lipnja 2012. 13:33 Matija Nalis mnalis-openstreetmapl...@voyager.hr je napisao/la: pa mogu ja, trebao bih slijedeci tjedan imati nesto slobodnog vremena. Ideja za realizaciju, pa komentirajte: Čini se sjajno. Ja mogu pomoći kod točke 5. 5) rucno popraviti/dodati podatke iz 4, pa ponoviti sve od 1 Ručno treba samo provjeriti mjesta koja ima u osm-u a nema u dzs-u, obrnuto ne možemo puno napraviti jer ne znamo gdje su mjesta koja nedostaju :) Višak mjesta možemo preimenovati u hamlet ili locality, ovisno o slučaju. I još nešto, moramo se dogovoriti što je city a što town. Trenutno lokal-patrioti svoja mjesta vole pretvoriti u city, makar nema osnove. U wikiju piše granica od 100.000, u što kod nas upadaju četiri najveća grada (OS, RI, ST, ZG). Ako se slažemo ostale možemo proglasiti town. Sela su točno odjeljena u xls-u pa za to ne trebamo izmišljati granicu. Dana 29. lipnja 2012. 13:58 hbogner hbog...@gmail.com je napisao/la: treba biti ili source:population=dzs.hr ili population:source=dzs.hr Našao sam source:population=* na slijedećoj stranici: http://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood Janko Mihelić ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[talk-ph] flickr updating its maps
Manila and Davao was one of the first city where flickr used OSM data. Now they are updating the maps with a new style. Some sources will come from Nokia's data but they will continue to use OSM in other areas. The current flickr map of Metro Manila is still an old osm mapnik style. It should be updated in the succeeding months. Post here: http://code.flickr.com/blog/2012/06/29/the-great-map-update-of-2012/ -- 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
[OSM-talk] How to move Potlatch map to specific coordinates whilst editing (without zooming out)?
Is there any way to move the map to a specific coordinates whilst editing in Potlatch and stay at the same zoom level? I know 1 way, which is to enter the coordinates into the search box, select the coordinates item from the search list and then say Cancel when it asks if you want to move away form the current page. A bit clunky, but it does work, but unfortunately the zoom level it then chooses for the new coordinates is quite small, so it then tries to download vast amounts of data (which can cause crashes/restarts of Potlatch or use up all the allowable bandwidth). This method would be liveable with if it didn't zoom out so much. Is there any easier way to do this that I haven't noticed? Thanks, Spod ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to move Potlatch map to specific coordinates whilst editing (without zooming out)?
Spod wrote: Is there any way to move the map to a specific coordinates whilst editing in Potlatch and stay at the same zoom level? You can use Potlatch's own search function - the little magnifying glass below the +/- zoom icons. It doesn't have any specific co-ordinate handling (I guess we could add that if desired) but just hands your search string off to Nominatim. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/How-to-move-Potlatch-map-to-specific-coordinates-whilst-editing-without-zooming-out-tp5714535p5714536.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to move Potlatch map to specific coordinates whilst editing (without zooming out)?
Ah, I hadn't seen that before - Thanks Richard! As you say, it's not quite what I was looking for, because Nominatim's nearest place to the coordinates can be a long way off the entered coordinates. If it handled coordinates directly, then that would be exactly what I need. I'll add something to trac about it. -- View this message in context: http://gis.19327.n5.nabble.com/How-to-move-Potlatch-map-to-specific-coordinates-whilst-editing-without-zooming-out-tp5714535p5714538.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] EU, Local and Online Volunteers: Key actors for inclusive humanitarian information-sharing in crisis preparedness - application
All, Below are two emails related to the application process for the EVHAC project in which HOT in partnership with OSM-FR is active. Best, Nicolas -- Forwarded message -- From: Séverin MENARD severin.men...@gmail.com Date: Fri, Jun 29, 2012 at 6:30 PM Subject: [HOT] EU, Local and Online Volunteers: Key actors for inclusive humanitarian information-sharing in crisis preparedness - applicaiton To: h...@openstreetmap.org *Hi EU, Local and Online Volunteers: The European Union wants to grow up a European Voluntary Humanitarian Aid Corps and will soon start an EU, Local and Online Volunteers: Key actors for inclusive humanitarian information-sharing in crisis preparedness program, involving young Europeans under 26 on 09/15/2012, proficient both in French and English, for a 6 months deployment in four African countries: Chad, Central African Republic, Burundi and Kenya. HOT in partnership with OSM-FR is one of the partners of this project, for training the volunteers to HOT/OSM mapping techniques and tools and supporting them through their deployment. The recruitment is done through France Volontaires International and other EU Volunteering organizations. The application is still open to everyone though the deadline is coming soon: next Monday July 2nd 11:59PM CET but the application form is rather short and does not demand any specific administrative document. All the information can be found here : http://france-volontaires.org/Appel-a-candidature-pour-le-projet http://france-volontaires.org/Appel-a-candidature-pour-le-projet In a coming message, we will furnish more details about HOT involvement and OSM scale up in these countries through this project. Sincerely * http://img4.hostingpics.net/pics/224326500pxHotlogowithtext.png * Severin MENARD Senior Project Lead France tel (+33) 9 70 46 75 95 Brazil tel1 (+55) 71 82 22 11 45 Brazil tel2 (+55) 71 33 44 55 71 Skype ID severin.menard * *= French version Bonjour, L'union Européenne cherche à développer un Corps Européen de Volontaires d’Aide Humanitaire et a lancé un programme Volontaires européens d’aide humanitaire open-source qui s'adresse à de jeunes Européens de moins de 26 ans au 15 septembre 2012, parlant anglais et français, pour un déploiement de 6 mois dans quatre pays africains : Chad, République Centrafricaine, Burundi et Kenya. Le HOT (Humanitarian OpenStreetMap Team) en partenariat avec OSM-FR (OpenStreetMap France) est l'un des nombreux partenaires de ce projet, intervenant sur la formation des volontaires aux techniques de cartographie propres à HOT et OSM et la fourniture d’un soutien opérationnel au long de ces quatre déploiements. La partie recrutement des volontaires est effectuée par France Volontaires Internationales et d’autres organisations de volontariat européennes. Les candidatures sont encore ouvertes à tous avec une date de clôture cependant très proche : lundi 2 juillet à 23h59 (CET), néanmoins, le dossier de cette phase de présélection est assez léger et ne nécessite aucune pièce administrative particulière (à part sans doute d'avoir déjà un passeport). Toutes les informations sont accessibles à cette adresse : http://france-volontaires.org/Appel-a-candidature-pour-le-projet http://france-volontaires.org/Appel-a-candidature-pour-le-projet Dans un prochain message, nous préciserons davantage lle rôle de HOT et le développement d'OSM dans ces pays dans le cadre de ce projet. * ___ HOT mailing list h...@openstreetmap.org http://lists.openstreetmap.org/listinfo/hot -- Nicolas Chavent Acting Project Director Humanitarian OpenStreetMap Team http://hot.openstreetmap.org/weblog/ Mobile (Senegal): +221 77 859 21 38 Mobile (Haiti): +509 4617 3334 Mobile (FRA): +33 (0)6 52 40 78 20 Email: nicolas.chav...@hotosm.org Skype: c_nicolas Twitter: nicolas_chavent ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Maandelijkse geo-borrels in Utrecht
Frank, Fijn je weer actief terug te zien. Zo heb ik je leren kennen en zo heb ik je leren waarderen. Wat ik op amsterdam tegen heb is dat je er onmogelijk per auto kunt komen. Wil je mij in Utrecht regelmatig tegen komen, ga dan niet in het centrum zitten, of zorg in iedetgeval dat er een betaalbaar plekje voor mijn stalen ros aanwezig is. Ik hoop tot snel. Met vriendelijke groeten Robert Elsenaar Frank Steggink stegg...@steggink.org schreef: Hoi, Ik wil graag maandelijks een geo-borrel organiseren in Utrecht. Deze is bedoeld om gezellig met elkaar te praten over open data en open source software op geo-gebied. Uiteraard is OSM een van de belangrijkste topics ;) De borrel is er op gericht om open (source/data) geo-kennis in Midden-Nederland bij elkaar te brengen. Dus als je hier woont en/of werkt, of als je het geen bezwaar vindt om van verder weg langs te komen, dan ben je van harte uitgenodigd! Het tijdstip is de laatste donderdag van de maand, zodat we niet in het vaarwater zitten van de Amsterdamse Mappersborrel. Ik denk dat 19:00 uur een goed moment is om open te gaan. Eventueel kunnen we eerst ergens eten, want iedereen komt terug van een lange werk-/studiedag. De locatie moeten we nog bepalen, dus als je een goede suggestie hebt, met name waar de muziek op donderdagavond niet te luid staat, laat het me dan s.v.p. weten. Een vaste locatie is wel zo praktisch, maar uiteraard kunnen we ook wel eens 'verhuizen'. De eerste borrel wil ik op donderdag 30 augustus organiseren, i.v.m. de vakantie. Eventueel kunnen we een proefdraaisessie organiseren op 26 juli a.s. Via de osgeo.nl meetup groep heb ik een meeting opgezet voor de 30e augustus: http://www.meetup.com/OSGeoNL/events/71140362/. Laat s.v.p. daar weten of je komt. Ik ga ook de wiki-pagina [1] http://wiki.openstreetmap.org/wiki/Utrecht op osm.org van Utrecht bijwerken, zodat je je ook daar kunt opgeven en niet een meetup-account hoeft aan te maken. De aanleiding van deze borrel is een oproep van Just van den Broecke op de zeer geslaagde eerste OSGeo.nl meeting (nederlandstalige open source geo-organisatie) in Velp om meer regionale meetings te houden. De OSGeo.nl conferentie was bijzonder interessant. OSM kwam regelmatig aan bod. Ook ons aller Henk hield een presentatie en Milo van der Linden heeft een workshop OSM gehouden. Het mooiste om te horen vond ik een presentatie van iemand van de veiligheidsregio Fryslân, waarin hij vertelde dat zij OSM als basislaag gebruikten, maar als de hulpmedewerkers (o.a. brandweermensen) fouten constateerden in de data, ze deze ook gingen aanpassen, zodat de volgende keer de kaart correct is! Kijk, dit soort toepassingen, met feedback van gebruikers van onze data, maakt OSM zo'n fantastisch project :) Groeten, Frank [1] http://wiki.openstreetmap.org/wiki/Utrecht ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Hi from Brett Russell
Hi I am an avid bushwalker and on a forum that I am on a fellow member mentioned OSM mapping. I have Garmin 62s and have been logging tracks with it and was looking for a way to improve upon the rather poor tracks on Tasmaps. So have been using OSM. It has been a steep learning curve but have been working on getting tracks uploaded and naming a few peaks. Also been working on creating lakes. Plus a bit of street naming and adding streets missed, mainly around the Devonport Area. I have zeroed in on the Walls of Jerusalem area adding named lakes at the moment. Any great project and no doubt will be looking for a few hints and ideas as well as standardw for defining streets and speed limits, etc, etc. Cheers Brett Russell PO Box 94 LAUNCESTON Tas 7250 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] Novas imagens do BIng
Ola, Incrível como a cada dia surge mais gente mapeando na Paraíba apos a inclusão das novas imagens do Bing. Acredito que falta apenas um site de visual legal para o osm deslanchar no brasil. -- Alexandre Parente Lima ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Novas imagens do BIng
Espírito Santo também tem cobertura melhor, agora incluindo mais entre Vitória e Linhares Aun Y. Johnsen Sent from my iPad On 29. juni 2012, at 20:17, Alexandre Parente Lima alexandre.pare...@gmail.com wrote: Ola, Incrível como a cada dia surge mais gente mapeando na Paraíba apos a inclusão das novas imagens do Bing. Acredito que falta apenas um site de visual legal para o osm deslanchar no brasil. -- Alexandre Parente Lima ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Falten von Plänen A4
Am 28.06.2012 21:29, schrieb hansdorfff: Hallo, Am 15. Mai 2012 19:18 schrieb Jan Tappenbeck o...@tappenbeck.net: kennt jemand eine gute Falttechnik für Stadtpläne (A4 / A3) die nicht mit irgendwelchen Patenten im Konflikt steht? Falls Du die alte Falttechnik von Falk meinst, das Patent [1] darauf ist schon ein paar Jahrzehnte abgelaufen (siehe z.B. auch [2]). Aber für A4 oder A3 macht das vermutlich gar keinen Sinn. Mir fällt noch Miura Map Fold ein, bin aber uninformiert, was die Patentlastigkeit betrifft: http://lifehacker.com/5888022/the-miura-fold-is-how-youd-fold-a-map-if-you-were-awesome Hier die Liste der Schutzrechte: http://www.miura-ori.com/English/e-Property.html Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, Am 28.06.2012 16:13, schrieb Sven Geggus: Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Vielleicht werden ja die Schlecker-Läden in meiner Gegend irgendwann von einer anderen Kette übernommen. In diesem Fall würde es mir die Arbeit erleichtern, wenn die noch in der einen oder anderen Form in der Datenbank wären. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, On 06/29/2012 09:10 AM, Rainer Kluge wrote: Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Bloss weil in der Zeitung steht, dass alle Schlecker-Filialen geschlossen werden, heisst das nicht, dass ich mir hier aus Karlsruhe anmassen kann, mit einem Bot in Elmshorn einen Schlecker-Markt zu loeschen oder auf disused zu setzen, den ich nie in meinem Leben gesehen habe. Was weiss ich denn davon? Ist ueberhaupt sicher, dass der POI, den ich da betrachte, wirklich ein Schlecker-Markt ist oder vielleicht ein lokaler Minimarkt, der eigenlich Schlacker heisst und wo der Mapper bloss einen Tippfehler gemacht hat, oder ob vielleicht ausgerechnet dieser Supermarkt von einem ortsansaessigen Kaufmann namens Schlecker gekauft und weiterbetrieben wird oder oder oder? Wir mappen nicht, was in Funk und Fernsehen kommt, wir mappen, was wir sehen! Ausserdem traegt ein in der Karte eingezeichneter Schlecker-Markt eine fuer den Benutzer wichtige Meta-Information: Hier vor Ort ist kein Mapper, der sich um solche Sachen kuemmert; ich muss daher damit rechnen, dass auch andere Aenderungen in Geschaeften in der Gegend nicht auf dem aktuellen Stand sind. So ehrlich duerfen wir auch ruhig sein: Wenn da keiner ist, der das geschlossen-Schild am Schlecker sieht und entsprechend bei uns eintraegt, dann ist das eben so. Eine zentrale, automatisierte Aenderung wuerde faelschlicherweise den Eindruck erwecken, die Karte sei supermarkt-technisch aktuell, selbst wenn nebendran noch ein Haus eingezeichnet ist, das vor einem halben Jahr abgerissen wurde. Also: Schlecker-Maerkte als geschlossen, disused, closed, was-auch-immer taggen - gern. Aber einzeln, von Mappern vor Ort, nicht zentral per Bot. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Moin, Am 28.06.2012 16:13, schrieb Sven Geggus: Moin, Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Nichts. Zum Einen kann wie gesagt der (old-)name ohne shop als Orientierung dienen. Zum Anderen befinden sich dort Ladenräume, die voraussichtlich wieder genutzt werden - warum willst Du also die POI-node-IDs unnötigerweise ins Nirwana befördern? Wenn schon automatisch, würde ich stattdessen den shop-key entfernen, den name-key ggf. auf old_name umbiegen - und die nodes zur Wiederverwendung belassen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Ich stimme Frederik hier zu. Entweder man hat eine sichere Quelle, dass es genau diesen Laden nicht mehr gibt, dann kann man ihn löschen oder was auch immer. Oder man vermutet nur, dann sollte man es besser lassen. Im Forum wurde noch angesprochen, dass operator=Schlecker durchaus auch an IhrPlatz-Läden getagt sein kann. Henning Am 29.06.2012 09:28, schrieb Frederik Ramm: Hallo, On 06/29/2012 09:10 AM, Rainer Kluge wrote: Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Bloss weil in der Zeitung steht, dass alle Schlecker-Filialen geschlossen werden, heisst das nicht, dass ich mir hier aus Karlsruhe anmassen kann, mit einem Bot in Elmshorn einen Schlecker-Markt zu loeschen oder auf disused zu setzen, den ich nie in meinem Leben gesehen habe. Was weiss ich denn davon? Ist ueberhaupt sicher, dass der POI, den ich da betrachte, wirklich ein Schlecker-Markt ist oder vielleicht ein lokaler Minimarkt, der eigenlich Schlacker heisst und wo der Mapper bloss einen Tippfehler gemacht hat, oder ob vielleicht ausgerechnet dieser Supermarkt von einem ortsansaessigen Kaufmann namens Schlecker gekauft und weiterbetrieben wird oder oder oder? Wir mappen nicht, was in Funk und Fernsehen kommt, wir mappen, was wir sehen! Ausserdem traegt ein in der Karte eingezeichneter Schlecker-Markt eine fuer den Benutzer wichtige Meta-Information: Hier vor Ort ist kein Mapper, der sich um solche Sachen kuemmert; ich muss daher damit rechnen, dass auch andere Aenderungen in Geschaeften in der Gegend nicht auf dem aktuellen Stand sind. So ehrlich duerfen wir auch ruhig sein: Wenn da keiner ist, der das geschlossen-Schild am Schlecker sieht und entsprechend bei uns eintraegt, dann ist das eben so. Eine zentrale, automatisierte Aenderung wuerde faelschlicherweise den Eindruck erwecken, die Karte sei supermarkt-technisch aktuell, selbst wenn nebendran noch ein Haus eingezeichnet ist, das vor einem halben Jahr abgerissen wurde. Also: Schlecker-Maerkte als geschlossen, disused, closed, was-auch-immer taggen - gern. Aber einzeln, von Mappern vor Ort, nicht zentral per Bot. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, ich bin auch nicht für automatisches Löschen oder umbenennen. Finde aber gut das es eine Diskussion darum gibt und dort Möglichkeiten der Abfrage zowie der Handlungsbedarf dargestellt wird. Denn wenn ich dann die Märkte in einigen Tagen oder Wochen bewußt ansehe, sehe ich ob es dort neue Filialen anderer Ketten gibt und wenn ich darauf achte nehme ich auch Daten in der Umgebung auf und so dürfte das Ergebnis besser werden als wenn ich mich einfach darauf verlasse das es ja irgend ein Automatismus regelt. LG Gisbert Am 29.06.2012 09:28, schrieb Frederik Ramm: Hallo, On 06/29/2012 09:10 AM, Rainer Kluge wrote: Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Bloss weil in der Zeitung steht, dass alle Schlecker-Filialen geschlossen werden, heisst das nicht, dass ich mir hier aus Karlsruhe anmassen kann, mit einem Bot in Elmshorn einen Schlecker-Markt zu loeschen oder auf disused zu setzen, den ich nie in meinem Leben gesehen habe. Was weiss ich denn davon? Ist ueberhaupt sicher, dass der POI, den ich da betrachte, wirklich ein Schlecker-Markt ist oder vielleicht ein lokaler Minimarkt, der eigenlich Schlacker heisst und wo der Mapper bloss einen Tippfehler gemacht hat, oder ob vielleicht ausgerechnet dieser Supermarkt von einem ortsansaessigen Kaufmann namens Schlecker gekauft und weiterbetrieben wird oder oder oder? Wir mappen nicht, was in Funk und Fernsehen kommt, wir mappen, was wir sehen! Ausserdem traegt ein in der Karte eingezeichneter Schlecker-Markt eine fuer den Benutzer wichtige Meta-Information: Hier vor Ort ist kein Mapper, der sich um solche Sachen kuemmert; ich muss daher damit rechnen, dass auch andere Aenderungen in Geschaeften in der Gegend nicht auf dem aktuellen Stand sind. So ehrlich duerfen wir auch ruhig sein: Wenn da keiner ist, der das geschlossen-Schild am Schlecker sieht und entsprechend bei uns eintraegt, dann ist das eben so. Eine zentrale, automatisierte Aenderung wuerde faelschlicherweise den Eindruck erwecken, die Karte sei supermarkt-technisch aktuell, selbst wenn nebendran noch ein Haus eingezeichnet ist, das vor einem halben Jahr abgerissen wurde. Also: Schlecker-Maerkte als geschlossen, disused, closed, was-auch-immer taggen - gern. Aber einzeln, von Mappern vor Ort, nicht zentral per Bot. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenexport von Strassennamen wird benötigt ( Suchen einen Programmierer der das Übernimmt )
Hallo, Am 28.06.2012 10:03, schrieb Gino Götz: Jemand brachte mich auf die Idee das man sie evtl aus openstreetmap extrahieren könnte. Ich habe zur Zeit leider nicht die Möglichkeit mich einzuarbeiten. Am elegantesten und effizientesten wäre sicher eine datenbankbasierte Lösung mit PostGis. Wenn du dafür keine fertige Lösung oder jemanden findest, der dir eine entwickelt, dann könnte man versuchen mit Perl und den XML-Extrakten etwas zu machen, zum Beispiel auf der Basis des Skripts sv-stat.pl von http://wiki.openstreetmap.org/wiki/User:Geo-francis Dieses Skript extrahiert die Strassennamen für eine Gemeinde, deren Grenzen als Polygon vorliegt. Man müsste also neben einigen anderen Anpassungen diese Grenzen aus OSM extrahieren. das setzt allerdings voraus, dass die Gemeindegrenzen für das betreffenden Land vollständig uns korrekt erfasst sind. Das ist allerdings auch für die PostGis-Lösung erforderlich. Wenn dich dieser Ansatz interessiert, dann kontaktiere mich per PM. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo Frederik, Am 29.06.2012 09:28, schrieb Frederik Ramm: On 06/29/2012 09:10 AM, Rainer Kluge wrote: Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Ich bin strikt gegen jede grossflaechige automatische Aenderung. Ich doch auch. Ich meinte: ich würde die Schlecker-Läden in meiner Gegend nicht löschen sondern manuell nach einem der angesprochenen Muster umtaggen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falten von Plänen A4
Ich bin nicht so sicher, dass die eigentliche Falt-Technik unter Patentschutz steht. Es könnte sein, dass die zitierten Rechte sich auf den Produktionsmechanismus beziehen, und nicht auf di eigentliche Faltung. Außerdem wurde die Falttechnik bereits 1980 veröffentlicht, d.h. eventuelle Patente sind möglicherweise erloschen. 2012/6/29 bkmap burkhard.kirch...@web.de Am 28.06.2012 21:29, schrieb hansdorfff: Hallo, Am 15. Mai 2012 19:18 schrieb Jan Tappenbeck o...@tappenbeck.net: kennt jemand eine gute Falttechnik für Stadtpläne (A4 / A3) die nicht mit irgendwelchen Patenten im Konflikt steht? Falls Du die alte Falttechnik von Falk meinst, das Patent [1] darauf ist schon ein paar Jahrzehnte abgelaufen (siehe z.B. auch [2]). Aber für A4 oder A3 macht das vermutlich gar keinen Sinn. Mir fällt noch Miura Map Fold ein, bin aber uninformiert, was die Patentlastigkeit betrifft: http://lifehacker.com/5888022/**the-miura-fold-is-how-youd-** fold-a-map-if-you-were-awesomehttp://lifehacker.com/5888022/the-miura-fold-is-how-youd-fold-a-map-if-you-were-awesome Hier die Liste der Schutzrechte: http://www.miura-ori.com/**English/e-Property.htmlhttp://www.miura-ori.com/English/e-Property.html Gruß Burkhard __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hi, wenn jemand was automatisches macht, dann denkt bitte daran, dass es z.B. auch österreichische Schlecker Filialen gibt, die (noch) nicht geschlossen sind. lg Leo Original-Nachricht Datum: Fri, 29 Jun 2012 09:41:17 +0200 Von: aighes o...@aighes.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Schlecker, die zweite Ich stimme Frederik hier zu. Entweder man hat eine sichere Quelle, dass es genau diesen Laden nicht mehr gibt, dann kann man ihn löschen oder was auch immer. Oder man vermutet nur, dann sollte man es besser lassen. Im Forum wurde noch angesprochen, dass operator=Schlecker durchaus auch an IhrPlatz-Läden getagt sein kann. Henning Am 29.06.2012 09:28, schrieb Frederik Ramm: Hallo, On 06/29/2012 09:10 AM, Rainer Kluge wrote: Ich denke ehrlich gesagt darüber nach alle die nodes automatisch zu löschen, wenn keine nützlichen Tags wie z.B. Adressen dran sind. Was haltet ihr davon? Würde ich nicht machen sondern eher einem der andern Vorschläge folgen (disused, old_name). Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Bloss weil in der Zeitung steht, dass alle Schlecker-Filialen geschlossen werden, heisst das nicht, dass ich mir hier aus Karlsruhe anmassen kann, mit einem Bot in Elmshorn einen Schlecker-Markt zu loeschen oder auf disused zu setzen, den ich nie in meinem Leben gesehen habe. Was weiss ich denn davon? Ist ueberhaupt sicher, dass der POI, den ich da betrachte, wirklich ein Schlecker-Markt ist oder vielleicht ein lokaler Minimarkt, der eigenlich Schlacker heisst und wo der Mapper bloss einen Tippfehler gemacht hat, oder ob vielleicht ausgerechnet dieser Supermarkt von einem ortsansaessigen Kaufmann namens Schlecker gekauft und weiterbetrieben wird oder oder oder? Wir mappen nicht, was in Funk und Fernsehen kommt, wir mappen, was wir sehen! Ausserdem traegt ein in der Karte eingezeichneter Schlecker-Markt eine fuer den Benutzer wichtige Meta-Information: Hier vor Ort ist kein Mapper, der sich um solche Sachen kuemmert; ich muss daher damit rechnen, dass auch andere Aenderungen in Geschaeften in der Gegend nicht auf dem aktuellen Stand sind. So ehrlich duerfen wir auch ruhig sein: Wenn da keiner ist, der das geschlossen-Schild am Schlecker sieht und entsprechend bei uns eintraegt, dann ist das eben so. Eine zentrale, automatisierte Aenderung wuerde faelschlicherweise den Eindruck erwecken, die Karte sei supermarkt-technisch aktuell, selbst wenn nebendran noch ein Haus eingezeichnet ist, das vor einem halben Jahr abgerissen wurde. Also: Schlecker-Maerkte als geschlossen, disused, closed, was-auch-immer taggen - gern. Aber einzeln, von Mappern vor Ort, nicht zentral per Bot. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Frederik Ramm frede...@remote.org wrote: Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Also lassen wir besser offensichtlichen Schrott in der Datenbank drin :( Sorry, aber das kann ich echt nicht nachvollziehen! Sollen wir wetten, dass es ohne ein irgendwie geartetes Lösch- oder Umbenennungsscript auch noch in einem Jahr Schleckermärkte auf der OSM Karte geben wird? Ich bin mir leider sehr sicher, dass das so ist. Gruss Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.c) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Am 29. Juni 2012 11:17 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Frederik Ramm frede...@remote.org wrote: Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. +1 Also lassen wir besser offensichtlichen Schrott in der Datenbank drin :( lieber als dass wir riskieren, gute Informationen im Übereifer zu löschen: ja. Die Beispiele von Frederik genauso wie der Hinweis von Leo aus Österreich zeigen doch, dass es so einfach nicht ist. Sollen wir wetten, dass es ohne ein irgendwie geartetes Lösch- oder Umbenennungsscript auch noch in einem Jahr Schleckermärkte auf der OSM Karte geben wird? Ich bin mir leider sehr sicher, dass das so ist. man kann ja einen Aufruf starten und alle Mapper bitten, in Ihrer Nähe den Schlecker Markt zu kontrollieren und ggf. umzutaggen oder zu löschen, ohne dass es dazu ein Script braucht. Oder automatisch eine Liste erstellen und irgendwo zur Verfügung stellen, damit man das abarbeiten kann. Prinzipiell sehe ich aber auch keinen Unterschied zwischen einem Schlecker-Markt und einem beliebigen anderen POI, ausser dass es bei Schlecker allgemein bekannt sein dürfte, dass es die mittlerweile nicht mehr gibt. Wenn dagegen das Restaurant zum goldenen Hirsch in Breitenhol ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Ich bin strikt gegen jede grossflaechige automatische Aenderung. Das entspricht einfach nicht der Art, wie wir arbeiten. Also lassen wir besser offensichtlichen Schrott in der Datenbank drin :( Sorry, aber das kann ich echt nicht nachvollziehen! Sollen wir wetten, dass es ohne ein irgendwie geartetes Lösch- oder Umbenennungsscript auch noch in einem Jahr Schleckermärkte auf der OSM Karte geben wird? Ich bin mir leider sehr sicher, dass das so ist. Wollen wir wetten, dass der Schrott, den der Bot produziert, auch in einem Jahr noch unkorrigiert in der Datenbank ist? Da tauschen wir nur 'veraltet' gegen 'falsch'. Jetzt kann man lange evaluieren, ob es mehr unkorrigierte Filialen oder Fehler des Bots geben wird, spätestens wenn man die erwähnte Gefahr des 'schlechten Beispiels für andere' mit einrechnet, dürfte es immer gegen automatisiert Edits ausgehen. Warum nicht an die best practice für Import halte?: Die Tools/Bots lieber automatisiert die zu ändernden Filialen finden lassen und sie, nach Region sortiert und in handlichen Arbeitspaketen, zum Abarbeiten und Abhaken ins Wiki stellen. Damit hat man das Beste beider Welten: die Gründlichkeit und Vollständigkeit der Bots und den gesunden Menschenverstand der lokalen Mapper. Über die filialen, die dort dann übrig bleiben, können wir dann immernoch diskutieren. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
sorry, die Mail ist mir entwischt, hier der Rest: die mittlerweile nicht mehr gibt. Wenn dagegen das Restaurant zum goldenen Hirsch in Breitenholz geschlossen wird, und das kein Mapper mitbekommt und aus der DB nimmt, dann wird das eher potentiell Probleme bereiten. Drogeriemärkte sind ja nun keine Notaufnahmen oder Rettungsstationen, von daher kann man es durchaus verstehen, wenn nun nicht gleich die Hälfte der Mapper in alle Richtungen ausschwärmt, um noch im letzten Winkel der Republik vor Ort zu kontrollieren, ob man da ggf. einen POI löschen muss. Vielleicht täusche ich mich (und Du Dich) allerdings auch, und in 2 Wochen sind keine falschen Schleckers mehr in der DB, ein Jahr ist ganz schön lang ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Am 29.06.2012 11:17, schrieb Sven Geggus: Also lassen wir besser offensichtlichen Schrott in der Datenbank drin :( Ich kann das Argument gegen willkürliche auftomatische Edits vollkommen nachvollziehen. Ich fände es viel besser, wenn z.B. es eine Liste geben würde und diese Liste manuell abgearbeitet wird. Bei automatischen Edits ist die Gefahr von Fehlern einfach zu groß... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Am 29.06.2012 09:32, schrieb Georg Feddern: Zum Einen kann wie gesagt der (old-)name ohne shop als Orientierung dienen. Oder ein disused == yes dazu. Grüße Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, Am 29.06.2012 11:17, schrieb Sven Geggus: Sollen wir wetten, dass es ohne ein irgendwie geartetes Lösch- oder Umbenennungsscript auch noch in einem Jahr Schleckermärkte auf der OSM Karte geben wird? Ich bin mir leider sehr sicher, dass das so ist. Wäre man dem Vorschlag in deinem ersten Beitrag zu dem Thema gefolgt, dann hätte das Skript auch Objekte mit name='Schlecker' gelöscht, bei denen es sich um gar keine Schleckermärkte handelt. Das Skript müsste deshalb sehr konservativ vorgehen. Somit blieben mit Sicherheit eine ganze Reihe von falsch/unkonventionell getaggten Schlecker-Läden übrig, bei denen man von Hand nacharbeiten muss. Dann kann man gleich das Ganze von Hand machen. Mit deinen Overpass-Abfragen und Josm sollte das auf regionaler Ebene ohne großen Aufwand gehen. Wenn jemand was Gutes tun will, dann kann er ja ein Tool entwickeln, welches noch existierende Schlecker-Filialen mit einen Remote-Control-Link zu Josm auflistet, oder dies als XML-Datei bereitstellt. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Martin Koppenhoefer dieterdre...@gmail.com wrote: lieber als dass wir riskieren, gute Informationen im Übereifer zu löschen: ja. Die Beispiele von Frederik genauso wie der Hinweis von Leo aus Österreich zeigen doch, dass es so einfach nicht ist. 99% der Schleckermärkte haben lediglich ein shop und ein name tag. Alle anders getaggten Nodes würde ich niemals automatisch löschen wollen. Allenfalls könnte man den shop und den name tag ändern. Prinzipiell sehe ich aber auch keinen Unterschied zwischen einem Schlecker-Markt und einem beliebigen anderen POI, Der Unterschide besteht darin, dass hier auf einen Schlag 2800 _bekannte_ POI obsolet werden. Gruss Sven -- Every time you use Google, you're using a Linux machine (Chris DiBona, a programs manager for Google) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Am 29. Juni 2012 11:51 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Martin Koppenhoefer dieterdre...@gmail.com wrote: lieber als dass wir riskieren, gute Informationen im Übereifer zu löschen: ja. Die Beispiele von Frederik genauso wie der Hinweis von Leo aus Österreich zeigen doch, dass es so einfach nicht ist. 99% der Schleckermärkte haben lediglich ein shop und ein name tag. Alle anders getaggten Nodes würde ich niemals automatisch löschen wollen. Allenfalls könnte man den shop und den name tag ändern. Die österreichischen hattest Du z.B. nicht auf dem Schirm, die wären vermutlich mit untergegangen, alleine schon deshalb können wir froh sein, dass wir keinen automatischen Bot losgeschickt haben. Der Unterschide besteht darin, dass hier auf einen Schlag 2800 _bekannte_ POI obsolet werden. naja, obsolet wird ja vor allem der shop-Wert. Solange da noch Schlecker dran steht (und das kann in manchen Regionen vielleicht auch noch in einem Jahr sein, falls kein Nachmieter gefunden wird), kann da der name=Schlecker evtl. durchaus bleiben (shop=vacant). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Martin Koppenhoefer wrote Die österreichischen hattest Du z.B. nicht auf dem Schirm, die wären vermutlich mit untergegangen, alleine schon deshalb können wir froh sein, dass wir keinen automatischen Bot losgeschickt haben. Ich traue Simon, der ja in CH steckt (?) , durchaus zu eine spatiale Abfrage zu machen. Es muss ja nicht immer die Overpass-Api sein. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/Schlecker-die-zweite-tp5714484p5714565.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schlecker XL
BTW: die Schlecker XL werden jetzt sehr wahrscheinlich auch platt gemacht (war gestern in den Nachrichten), siehe auch Wikipedia. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, On 06/29/12 11:17, Sven Geggus wrote: Sollen wir wetten, dass es ohne ein irgendwie geartetes Lösch- oder Umbenennungsscript auch noch in einem Jahr Schleckermärkte auf der OSM Karte geben wird? Ich bin mir leider sehr sicher, dass das so ist. Wie ich bereits gesagt habe: Das ist doch gut. Dann sehe ich als ganz normaler Map-Benutzer ohne jede Spezial-OSM-Kenntnisse und ohne Zugang zu speziellen APIs, dass sich hier seit einem Jahr niemand drum gekuemmert hat. Mag ja sein, dass das offensichtlicher Schrott ist. Aber wenn an einem Ort niemand Zeit und Lust hat, den in OSM vorhandenen, aber lang geschlossenen Schlecker-Markt zu fixen, dann wird er auch den Blumenladen nebenan, der laengst ein Nagelstudio ist, nicht fixen, und auch nicht die Telefonzelle vor dem Schlecker-Markt, die laengst wegen Vandalismus abgebaut wurde. Das Problem von einem solchen Ort ist ganz bestimmt nicht das, dass da ein Schlecker-Markt eingezeichnet ist, der inzwischen zu hat, das Problem ist, dass niemand sich kuemmert. Wenn Du jetzt zentral die Schlecker-Maerkte korrigierst (mal ganz abgesehen davon, dass Du wirklich nicht wissen kannst, ob Dein automatischer Edit in jedem Fall korrekt ist), dann uebertuenchst Du dieses keiner-kuemmert-sich-um-diese-Gegend-Problem (oder schlimmer noch: Du suggerierst, man muesse sich ja gar nicht kuemmern, weil das ja alles ein Bot macht). Aber *eigentlich* muesstest Du Dich auf Dein Fahrrad setzen und das Nagelstudio und die Telefonzelle auch machen. Und wenn Du dazu zu weit weg bist - dann lass es doch gleich ganz, und lass die Locals sich drum kuemmern. Die Staerke von OSM sind nicht irgendwelche Hacker, die Skripts schreiben und Zeugs aendern, das sie niemals mit eigenen Augen gesehen haben. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falten von Plänen A4
Hallo, das Patent von miura-ori ist zwar noch recht jung, es gibt aber wohl nur eines in Japan. Solange es also nicht um ein globales Geschäft geht, sollte das kein Problem darstellen... Grüße Michael Am 29. Juni 2012 09:57 schrieb Volker Schmidt vosc...@gmail.com: Ich bin nicht so sicher, dass die eigentliche Falt-Technik unter Patentschutz steht. Es könnte sein, dass die zitierten Rechte sich auf den Produktionsmechanismus beziehen, und nicht auf di eigentliche Faltung. Außerdem wurde die Falttechnik bereits 1980 veröffentlicht, d.h. eventuelle Patente sind möglicherweise erloschen. 2012/6/29 bkmap burkhard.kirch...@web.de Am 28.06.2012 21:29, schrieb hansdorfff: Hallo, Am 15. Mai 2012 19:18 schrieb Jan Tappenbeck o...@tappenbeck.net: kennt jemand eine gute Falttechnik für Stadtpläne (A4 / A3) die nicht mit irgendwelchen Patenten im Konflikt steht? Falls Du die alte Falttechnik von Falk meinst, das Patent [1] darauf ist schon ein paar Jahrzehnte abgelaufen (siehe z.B. auch [2]). Aber für A4 oder A3 macht das vermutlich gar keinen Sinn. Mir fällt noch Miura Map Fold ein, bin aber uninformiert, was die Patentlastigkeit betrifft: http://lifehacker.com/5888022/**the-miura-fold-is-how-youd-** fold-a-map-if-you-were-awesome http://lifehacker.com/5888022/the-miura-fold-is-how-youd-fold-a-map-if-you-were-awesome Hier die Liste der Schutzrechte: http://www.miura-ori.com/**English/e-Property.html http://www.miura-ori.com/English/e-Property.html Gruß Burkhard __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-de http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo, evtl. könnte man nach dem Abarbeiten einer Liste auch OSB bemühen und dort die restlichen vermeintlichen Schleckermärkte eintragen, die noch in der DB sind. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Manueller Rückbau der Schlecker Märkte!
Hallo Leute, da eine Mehrzahl der Leute hier keinen automatischen Rückbau der Schleckermärkte wünscht lasst uns also den manuellen Rückbau angehen :) Damit das einfacher geht habe ich schnell mal eine Quick and Dirty Schleckermap zusammengezimmert, da könnt ihr dann mal schauen wo es in eurer Nähe noch eigetragene Märkte gibt und die dann passend bearbeiten oder löschen. Letzteres würde ich für Märkte empfehlen, die definitiv geschlossen haben und die lediglich aus Nodes mit name=Schlecker/shop=* bestehen. Im Minimalfall sollte aber auf jeden Fall name verschwinden und die shop Kathegorie. http://schlecker.openstreetmap.de/ Das ganze ist derzeit etwas lahm, weil es noch zu viele Schleckermärkte gibt, aber das kann ja nur besser werden :) Gruss Sven, der gerade dabei mithilft seine eigene Wette zu verlieren -- Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der Demokraten (Theodor W. Adorno) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OL 2.12 mit dem Effekt des Kartenanzeigens
Moin ! die OSM-Karte kommt jetzt wohl auch mit der OL 2.12 Version daher. Aber mal ehrlich - wer hat sich denn diesen Mist-Effekt ausgedacht ? Weiß schon einer ob man das irgendwie abschalten kann? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OL 2.12 mit dem Effekt des Kartenanzeigens
Danke für die Info! Ich finde diesen Effekt sehr angenehm, weil er das Flackern beim Zoomen verhindert. Zuerst habe ich ihn bei Google Maps gesehen und in ähnlicher Form (so weit ich mich erinnere) bei LeafLet. Ich mag's :) -- View this message in context: http://gis.19327.n5.nabble.com/OL-2-12-mit-dem-Effekt-des-Kartenanzeigens-tp5714586p5714592.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Manueller Rückbau der Schlecker Märkte!
Hallo, On 06/29/2012 02:11 PM, Sven Geggus wrote: Damit das einfacher geht habe ich schnell mal eine Quick and Dirty Schleckermap zusammengezimmert, da könnt ihr dann mal schauen wo es in eurer Nähe noch eigetragene Märkte gibt und die dann passend bearbeiten oder löschen. ... nachdem ihr selbst vorbeigegangen/gefahren seid und Euch von der Lage vor Ort ueberzeugt habt, nicht wahr ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Manueller Rückbau der Schlecker Märkte!
Frederik Ramm frede...@remote.org wrote: ... nachdem ihr selbst vorbeigegangen/gefahren seid und Euch von der Lage vor Ort ueberzeugt habt, nicht wahr ;) Das habe ich ja nicht in Abrede gestellt. BTW, hier in meinem Stadtteil gibts anscheinend keinen, aber der hier ist ganz in der Nähe der Geofabrik: http://www.openstreetmap.org/browse/node/827172088 Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OL 2.12 mit dem Effekt des Kartenanzeigens
jan99 wrote Weiß schon einer ob man das irgendwie abschalten kann? ja klar, kannst alles im forum lesen: http://forum.openstreetmap.org/viewtopic.php?pid=251816#p251816 und http://forum.openstreetmap.org/viewtopic.php?pid=251845#p251845 gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/OL-2-12-mit-dem-Effekt-des-Kartenanzeigens-tp5714586p5714603.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker, die zweite
Hallo an alle, solange das Schild SCHLECKER noch montiert ist, finde ich name = Schlecker immer noch völlig korrekt, der Name ist ja nicht einmal disused oder gar abandoned und OSM zeigt, was in der Realität vorhanden ist. Zurzeit ist bei den meisten vermutlich nur der shop = disused. Statt dem unkontrollierten Löschen, Ändern oder sonstwas, finde ich die Karte http://schlecker.openstreetmap.de/ sehr gut, hier kann man übersichtlich sehen, wo man gelegentlich mal vorbei gehen sollte um den aktuellen Stand zu notieren. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Manueller Rückbau der Schlecker Märkte!
Am 29.06.2012 14:11, schrieb Sven Geggus: http://schlecker.openstreetmap.de/ Sehr schön! Danke. Eine Warnung an übereifrige Mapper: die Karte hat auch alle Schlecker-Märkte im Ausland ( DE) enthalten. Diese sind nicht zwingend zu löschen! Hintergrund: z.B. in Österreich gibt es Verhandlungen, dass die ganzen Märkte von einer anderen Kette übernommen werden. Siehe auch: http://de.wikipedia.org/wiki/Schlecker#Entwicklungen_ab_2011 (fast am Ende des Kapitels) Grüße, Michael. PS: die nicht saubere Abgrenzung auf Deutschland war einer der Gründe, dass ich einige Personen gegen eine automatische Änderung ausgesprochen haben... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bund stellt Geodaten kostenfrei bereit
Hallo, Meldung bei Heise: http://www.heise.de/newsticker/meldung/Bund-stellt-Geodaten-kostenfrei-bereit-1629289.html Was sind denn Geographische Informationen des Bundes? Können wir damit was anfangen? Welche Art der Nutzung ist erlaubt? Import/Abgleich per Overlay? Grenzen vielleicht? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bund stellt Geodaten kostenfrei bereit
Stephan Knauss o...@stephans-server.de wrote: Was sind denn Geographische Informationen des Bundes? Können wir damit was anfangen? Luftbilder vom BKG vielleicht? Immerhin Bundesweit mit 30cm bzw. 25cm Auflösung verfügbar. Aber eigentlich hat das BKG das Zeug ja alles aus den Ländern. Gruss Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 28/06/2012 19.00, gpstracks.it ha scritto: Propongo una regola semplice e pragmatica: Dove l'indicazione bilingue è obbligatoria (penso TAA), indicare name=* / * Dove invece si premette che: [cit. art. 8 L. 38/2001 ] Fermo restando il carattere ufficiale della lingua italiana... mettere name=italiano ed aggiungere name:fur=* name:sl=* ecc. (vedi FVG minoranze friulana, slovena, tedesca, bisiaca, veneta...) Perché questi *sono* i valori di name nelle varie lingue e perché è *molto* più semplice utilizzare i dati inseriti in quest'ultimo modo. Ricordo che OSM è un database. Nessuno si senta offeso. +1 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
mettere name=italiano ed aggiungere name:fur=* name:sl=* ecc. (vedi FVG minoranze friulana, slovena, tedesca, bisiaca, veneta...) Perché questi *sono* i valori di name nelle varie lingue e perché è *molto* più semplice utilizzare i dati inseriti in quest'ultimo modo. Io sono daccordo, quindi procediamo a sistemare anche i nomi sloveni in provincia di Trieste ? Esistono eccezioni significative alla regola che possiamo elencare nel wiki ? Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Stefano Salvador: mettere name=italiano ed aggiungere name:fur=* name:sl=* ecc. (vedi FVG minoranze friulana, slovena, tedesca, bisiaca, veneta...) Perché questi *sono* i valori di name nelle varie lingue e perché è *molto* più semplice utilizzare i dati inseriti in quest'ultimo modo. Io sono daccordo, quindi procediamo a sistemare anche i nomi sloveni in provincia di Trieste ? Esistono eccezioni significative alla regola che possiamo elencare nel wiki ? Non sono assolutamente d'accordo. Così va a perdersi l'informazione della visibilità della bilinguità del posto (non so se in italiano si dice così). Il name:sl=* può esserci anche se sui cartelli ecc. non c'è questo nome (vedi per es. Venezia), quindi a parte se uno non conosca la zona assolutamente non riesce a rendersi conto che quella è una zona bilingue. E' quello che ha fatto l'Italia per una settantina e più di anni (nella mia zona) e che ha cercato di riparare proprio con la legge citata in soggetto e la legge di tutela globale della minoranza slovena n. 38/2001. Così come è adesso in osm per la provincia di Trieste e Gorizia direi che è la cosa ottimale e la più giusta anche nei confronti della minoranza slovena. Almeno io la penso così. Spero che OSM non diventi come gmaps che dopo qualche decina di anni alcuni nomi di località ecc. rimangono palesemente sbagliati e non rispecchiano la realtà. Basterebbe che gmaps andrebbe a guardare le proprie foto street-maps! Ovviamente se la comunità decidesse di procedere in questo modo per la provincia di Trieste, dovrebbe OVVIAMENTE procedere lo stesso per tutta l'Italia, quindi nomi in name=* assolutamente solo italiani dapertutto!!! Anzi, anche fuori dall'Italia bisognerebbe rimettere a posto tutto, tutte le zone bilingui che ci sono nel mondo e che sono così segnate. Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Non sono assolutamente d'accordo. Così va a perdersi l'informazione della visibilità della bilinguità del posto (non so se in italiano si dice così). Tieni presente che quando parli di visibilità stai parlando di un particolare rendering dei dati OSM, che è quello che compare nella home page di OpenStreetMap.org. Ma OSM è prima di tutto un database e nel database tutte le varie lingue hanno uguale visibilità e consentono la produzione delle più volte citate mappe nelle varie lingue (dove, vorrei sottolineare, sono segnati nella lingua selezionata non solo i toponimi in una piccola porzione di terra, ma di tutto il mondo). IMHO, senza riprendere guerre imperialistiche, dobbiamo però essere pragmatici e trovare una linea di demarcazione. Ogni angolo d'Italia ha il suo dialetto/lingua che rappresenta una ricchezza per la cultura, ma se cominciamo dappertutto a mettere toponimi tri-quadri lingue otteniamo una mappa che non serve a niente. Piuttosto aboliamo il tag name nei contesti bilingui ... Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
2012/6/29 Stefano Salvador stefano.salva...@gmail.com: Non sono assolutamente d'accordo. Così va a perdersi l'informazione della visibilità della bilinguità del posto (non so se in italiano si dice così). Tieni presente che quando parli di visibilità stai parlando di un particolare rendering dei dati OSM, credo che Damjan sta parlando dei cartelli stradali. Ho ripensato e sono d'accordo con lui: quando nella realtà i cartelli sono bilungue sarebbe da inserirle anche in OSM così (in più ovviamente name:it, name:sl ecc., ma lì credo che non ci sia dissenso). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 29/06/2012 11.05, Stefano Salvador ha scritto: IMHO, senza riprendere guerre imperialistiche, dobbiamo però essere pragmatici e trovare una linea di demarcazione. Ogni angolo d'Italia ha il suo dialetto/lingua che rappresenta una ricchezza per la cultura, ma se cominciamo dappertutto a mettere toponimi tri-quadri lingue otteniamo una mappa che non serve a niente. Piuttosto aboliamo il tag name nei contesti bilingui ... Ciao, Stefano +1 Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Ho ripensato e sono d'accordo con lui: quando nella realtà i cartelli sono bilungue sarebbe da inserirle anche in OSM così Il problema è che al nord trovi praticamente ovunque cartelli bilingui (e per ovunque si intende proprio dappertutto). Non credo di dire niente di nuovo se faccio notare che la cosa è spesso una questione politica e i cartelli vanno e vengono come le giunte comunali. Io terrei fuori OSM da questi discorsi. In Italia ci sono delle zone storicamente bilingue nel senso stretto della parola, cioè dove posso condurre tranquillamente la mia vita conoscendo o una o l'altra lingua e dove per accedere ad un posto pubblico devo conoscere entrambe le lingue. Questi posti sono limitati alla Provincia Autonoma di Bolzano e a varie (piccole) aree lungo i vari confini. IMHO segnerei quali sono queste aree sul wiki (ovviamente con un minimo di elasticità) e mi fermerei li. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
piše Stefano Salvador: Tieni presente che quando parli di visibilità stai parlando di un particolare rendering dei dati OSM, che è quello che compare nella home page di OpenStreetMap.org. Ma OSM è prima di tutto un database e nel database tutte le varie lingue hanno uguale visibilità e consentono la produzione delle più volte citate mappe nelle varie lingue (dove, vorrei sottolineare, sono segnati nella lingua selezionata non solo i toponimi in una piccola porzione di terra, ma di tutto il mondo). Ecco, appunto. Se uno vuole avere la visualizzazione solo in una data lingua può benissimo usare un altro rendering... Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il giorno 29 giugno 2012 11:36, Stefano Salvador stefano.salva...@gmail.com ha scritto: Ho ripensato e sono d'accordo con lui: quando nella realtà i cartelli sono bilungue sarebbe da inserirle anche in OSM così Il problema è che al nord trovi praticamente ovunque cartelli bilingui (e per ovunque si intende proprio dappertutto). Non credo di dire niente di nuovo se faccio notare che la cosa è spesso una questione politica e i cartelli vanno e vengono come le giunte comunali. Io terrei fuori OSM da questi discorsi. In Italia ci sono delle zone storicamente bilingue nel senso stretto della parola, cioè dove posso condurre tranquillamente la mia vita conoscendo o una o l'altra lingua e dove per accedere ad un posto pubblico devo conoscere entrambe le lingue. Questi posti sono limitati alla Provincia Autonoma di Bolzano e a varie (piccole) aree lungo i vari confini. IMHO segnerei quali sono queste aree sul wiki (ovviamente con un minimo di elasticità) e mi fermerei li. Ricordo anche la mia domanda sui nomi nizzardi intorno a Nizza. Non solo sulle targhe dei nomi delle strade, ma proprio anche entrando in Nizza si vedono cartelli con Nice / Nissa / Nizza. Anche in Piemonte capita che qualche associazione culturale faccia pressione sul Comune e ottenga di mettere il nome in piemontese sui cartelli stradali. Ma non ritengo che questo debba entrare in name. Ho l'impressione, però, che stiamo iniziando la solita discussione dei mille giorni. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 29/06/2012 13.24, Simone Saviolo ha scritto: Ricordo anche la mia domanda sui nomi nizzardi intorno a Nizza. Non solo sulle targhe dei nomi delle strade, ma proprio anche entrando in Nizza si vedono cartelli con Nice / Nissa / Nizza. Anche in Piemonte capita che qualche associazione culturale faccia pressione sul Comune e ottenga di mettere il nome in piemontese sui cartelli stradali. Ma non ritengo che questo debba entrare in name. Ho l'impressione, però, che stiamo iniziando la solita discussione dei mille giorni. Ciao, Riporto testualmente dalla wiki cosa indica la chiave name: The common default name. (Note: For disputed areas, please use the name as displayed on e.g. street signs for the name tag. Put all alternatives into either localized name tags (e.g. name:tr/name:el) or the variants (e.g. loc_name/old_name/alt_name). Thank you. Il nome standard più diffuso/noto. Gli altri nomi vanno sui tag locali... Per la Val d'Aosta e il TAA il nome è bilingue, passatemi il termine, nella sostanza. Nel friulano non c'è bilinguismo ma solo lingue tutelate e questo è ben differente. Name è un singolo nome (1) non una cozzaglia di nomi. Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il giorno 29 giugno 2012 13:57, Stefano Fraccaro stefano.fracc...@libero.it ha scritto: Il 29/06/2012 13.24, Simone Saviolo ha scritto: Ricordo anche la mia domanda sui nomi nizzardi intorno a Nizza. Non solo sulle targhe dei nomi delle strade, ma proprio anche entrando in Nizza si vedono cartelli con Nice / Nissa / Nizza. Anche in Piemonte capita che qualche associazione culturale faccia pressione sul Comune e ottenga di mettere il nome in piemontese sui cartelli stradali. Ma non ritengo che questo debba entrare in name. Ho l'impressione, però, che stiamo iniziando la solita discussione dei mille giorni. Ciao, Riporto testualmente dalla wiki cosa indica la chiave name: The common default name. (Note: For disputed areas, please use the name as displayed on e.g. street signs for the name tag. Put all alternatives into either localized name tags (e.g. name:tr/name:el) or the variants (e.g. loc_name/old_name/alt_name). Thank you. Penso che siamo tutti d'accordo sul fatto che il Friuli e la Venezia Giulia non sono più aree contese :-) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
piše Stefano Fraccaro: Per la Val d'Aosta e il TAA il nome è bilingue, passatemi il termine, nella sostanza. Nel friulano non c'è bilinguismo ma solo lingue tutelate e questo è ben differente. Name è un singolo nome (1) non una cozzaglia di nomi. Se per friulano intendi la lingua non so, pero se intendi il FVG allora devo dissentire. Per lo sloveno nella provincia di TS e GO vale la stessa cosa che nel TAA e nella V d'A: bilinguismo. Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 28/06/2012 14:25, Damjan Gerl ha scritto: Credo sia giusto scrivere in name=* quello che si trova scritto sul posto (su cartelli stradali) Il 29/06/2012 11:16, Martin Koppenhoefer ha scritto: quando nella realtà i cartelli sono bilungue sarebbe da inserirle anche in OSM così Ok, ma parliamo del cartello bianco (limite centro abitato) o del cartello marrone (limite comune)? O basta la presenza di un generico cartello (anche aggiuntivo)? Oppure il riferimento è ai segnali di direzione? (vedere [1]) Il 29/06/2012 11:36, Stefano Salvador ha scritto: In Italia ci sono delle zone storicamente bilingue nel senso stretto della parola, cioè dove posso condurre tranquillamente la mia vita conoscendo o una o l'altra lingua e dove per accedere ad un posto pubblico devo conoscere entrambe le lingue. Non mi risulta ci siano zone in cui è possibile non conoscere la lingua ufficiale dello stato (vorrebbe dire che a scuola non viene insegnato l'italiano nemmeno come seconda lingua). Comunque, credo d'aver capito che per te il criterio discriminante dovrebbe essere una cosa tipo nei comuni ove è possibile fare la carta d'identità bilingue si mette la doppia denominazione nel name. In tal caso si limiterebbe l'uso del doppio name ai comuni sloveni della sola Provincia di Trieste, ai comuni della provincia di Bolzano e a quelli della Val d'Aosta (che poi per la Valle d'Aosta il problema c'è solo per il comune di Aosta e per il nome della regione, dato che tutti gli altri toponimi it non sono più ufficiali). ciao Paolo M [1] http://it.wikipedia.org/wiki/Segnaletica_bilingue#Italia ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 29/06/2012 16.02, Paolo Monegato ha scritto: Non mi risulta ci siano zone in cui è possibile non conoscere la lingua ufficiale dello stato (vorrebbe dire che a scuola non viene insegnato l'italiano nemmeno come seconda lingua). In provincia di Bolzano è così... se conosci solo il tedesco sei a posto. Forse anche in quella di Trento ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il giorno 29 giugno 2012 16:09, Stefano Fraccaro stefano.fracc...@libero.it ha scritto: Il 29/06/2012 16.02, Paolo Monegato ha scritto: Non mi risulta ci siano zone in cui è possibile non conoscere la lingua ufficiale dello stato (vorrebbe dire che a scuola non viene insegnato l'italiano nemmeno come seconda lingua). In provincia di Bolzano è così... se conosci solo il tedesco sei a posto. Forse anche in quella di Trento In maniera ufficiosa. Non faccio fatica a credere che tu possa passare tutta la vita chiuso nella valle senza sapere una parola d'italiano (conosco gente del posto). Ma su tutto il territorio italiano ci si aspetta che un italiano sappia l'italiano. Se arriva un carabiniere che ti chiede Patente e libretto e tu sai solo rispondergli ich sprache nicht Italienisch, non credo che la legge lo consenta (che poi il carabiniere si pieghi e parli in tedesco è un altro discorso :-) ). Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 29/06/2012 16:09, Stefano Fraccaro ha scritto: Il 29/06/2012 16.02, Paolo Monegato ha scritto: Non mi risulta ci siano zone in cui è possibile non conoscere la lingua ufficiale dello stato (vorrebbe dire che a scuola non viene insegnato l'italiano nemmeno come seconda lingua). In provincia di Bolzano è così... se conosci solo il tedesco sei a posto. Forse anche in quella di Trento Mi risulta che, nelle scuole di lingua tedesca, a partire dalle elementari venga insegnato l'italiano come seconda lingua. Quindi chi è andato a scuola l'italiano dovrebbe saperlo. Che poi una persona possa vivere parlando solo tedesco è un altro discorso. http://it.wikipedia.org/wiki/Lingue_della_provincia_autonoma_di_Bolzano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Comunque, credo d'aver capito che per te il criterio discriminante dovrebbe essere una cosa tipo nei comuni ove è possibile fare la carta d'identità bilingue si mette la doppia denominazione nel name. In tal caso si limiterebbe l'uso del doppio name ai comuni sloveni della sola Provincia di Trieste, ai comuni della provincia di Bolzano e a quelli della Val d'Aosta Mettici anche i comuni delle Valli del Natisone (tra cui Cividale del Friuli / Čedad) e Val Resia, tutti in provincia di Udine. All'anagrafe c'è qualche intoppo [1], dovuto ad un maleinterpretato patriottismo delle amministrazioni. Ovviamente non è questo il luogo per discuterne, ma le tensioni non si sono mai sopite. [1] http://messaggeroveneto.gelocal.it/cronaca/2012/04/13/news/carte-d-identita-bilingui-e-bufera-sul-comune-1.4023066 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Domanda: in FVG esistono scuole pubbliche in cui si faccia lezione in sloveno? Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Sì. Tipo questa http://www.solskicenter.net/drupal/it a Gorizia (liceo) 2012/6/29 Carlo Stemberger carlo.stember...@gmail.com Domanda: in FVG esistono scuole pubbliche in cui si faccia lezione in sloveno? Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
29/06/2012 19.48.55 - Carlo Stemberger: Domanda: in FVG esistono scuole pubbliche in cui si faccia lezione in sloveno? si. E ci sono anche la carta di identità, i moduli per la dichiarazione dei redditi, etc, in sloveno. -- Sans ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Il 29 giugno 2012 19:48, Carlo Stemberger carlo.stember...@gmail.com ha scritto: Domanda: in FVG esistono scuole pubbliche in cui si faccia lezione in sloveno? Certo, queste [1] (da quella d'infanzia fino alle medie) le trovi nel solo comune di Duino-Aurisina / Devin Nabrežina (TS) A San Pietro al Natisone (UD) c'è pure un istituto bilingue [2] [1] http://www.comuni-italiani.it/032/001/scuole/ [2] http://www.ragazzidelfiume.it/?page_id=1591 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
Carlo Stemberger: Domanda: in FVG esistono scuole pubbliche in cui si faccia lezione in sloveno? Carlo Si, in tutti i comuni della provincia di Trieste, pure Trieste centro. Personalmente ho fatto tutte le scuole slovene, dall'asilo nel mio paese alle superiori a Trieste. Poi anche in Provincia di Gorizia ce ne sono tante ed anche in provincia di Udine (S.Pietro al Natisone). Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] toponimi bilingue lingue minoritarie L.482/99
gpstracks.it: Per curiosità: Perché non sono stati cambiati i nomi di Trieste (Trieste / Trst) o Gorizia (Gorizia / Gorica)? Perché come ho già scritto il Comune di Trieste non ha nello statuto la menzione del bilinguismo, anche se tutti i paesi fuori centro sono stati dotati comunque di cartelli stradali bilingui (però ci sono scuole slovene, circoli sloveni, associazioni di venditori, biblioteca, libreria, giornale, ecc.) E cosa succederebbe se questo venisse fatto? Sarebbe giusto... Ed ancora: perché in questo caso si usano due pesi e due misure? Ciao Vedi sopra Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Una propuesta para mapear pueblos indígenas
Listo, tarea perfecta para Botika. @Federico: podrías agregar Colombia a la tabla en la página del wiki de protected_area [0] y hacer esa salvedad. Después en el renderer podemos hacerlo parecido a los límites administrativos. Yo me ofrezco a ir por la parte del Chocó, si no hay alguien que conozca mejor la zona. Am Donnerstag, den 28.06.2012, 18:05 -0500 schrieb Federico Explorador (Nevados.org): Hola Germán y colegas: Muchas gracias por tu planteamiento, que enriquece la discusión. Comparto con tigo que boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado. Bien podríamos usarlo para los resguardos indígenas, como también para los territorios colectivos de la población afrodescendiente. Sin embargo, me parece que con la afirmación usar boundary=administrative crea más problemas que soluciones ... ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, no estás en lo correcto. Los resguardos indígenas son entidades territoriales o pueden adquirir este status, administrando su territorio con cierta autonomía, de acuerdo a la constitución y las leyes de ordenamiento territorial. Reciben recursos del Estado a través de los municipios e incluso pueden adquirir incluso el estatus de un municipio. (ver documento DNP, [1]). Si propuse usar el valor boundary=administrative, admin_level=7 (un nivel debajo de municipio), era para reconocer a los pueblos indígenas precisamente este derecho de autonomía administrativa en sus territorios. Sí es cierto de que en la mayoría de casos, el territorio municipal y el territorio indígena no colindan, sino se solapan o el último está dentro del otro; así que no hay linderos compartidos. El valor protected area enfoca la protección (de la naturaleza o de un grupo humano) a la cual por cierto los indígenas también tienen derecho (Para los más interesados, hay un link con un ejemplo desde la visión indígena en [2]. Lo malo es que ambos conceptos, el de protección y el de administración, pasan por el tag boundary, así que tenemos que decidirnos por uno de los dos. Para mí está bien trabajar con protected_area, pero quería hacer la aclaración anterior. Lo importante que establezcamos un estándar con el cual podemos generar mapas que visualicen los resguardos. Entonces tendríamos para los resguardos: boundary=protected_area protect_class=24 ethnic_group=* Como en la actualidad muchos resguardos figuran ya en OSM producto de una importación, incluso podría haber una tarea para botica. Los imports vienen, entre otros, con ETNIA=*, entonces botica podría adicionar a todas las entradas con ETNIA=* el valor boundary=protected_area, protect_class=24 y luego sustituir ETNIA por ethnic_group. Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Saludos, Federico [1] http://www.dnp.gov.co/LinkClick.aspx?fileticket=CpCS1dVTQf4%3Dtabid=273 [2] Ejemplo desde la visión indígena (wayúu): http://www.unisi.it/cisai/wayuu.htm -Mensaje original- De: Germán Márquez Mejía [mailto:manch...@gmail.com] Enviado el: jueves, 28 de junio de 2012 09:52 a.m. Para: OpenStreetMap Colombia Asunto: Re: [Talk-co] Una propuesta para mapear pueblos indígenas No soy partdario de usar boundary=administrative. Crea más problemas que soluciones e interfiere con el esquema que tenemos, ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, de manera que puede darse el caso de un resguardo con partes de su territorio en varios municipios y problemas con la distorsión de la extensión real de los corregimientos. boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado y elaborado (por algo fue aceptado). Con boundary=protected_area basta y sobra y, si se ve o no en Mapnik, como lo han dicho, no es argumento para desecharlo o para meterle etiquetas que no corresponden (administrative). Al fin y al cabo, con el renderer colombiano se pueden hacer visibles en el futuro, o ahora, con una capa Vector en OL. Así que propongo no mezclar peras con manzanas y usar solo boundary=protected_area. Am Mittwoch, den 27.06.2012, 23:32 -0500 schrieb Federico Explorador (Nevados.org): Para responder más cosas a Edwin y a mí mismo: Probando, me he dado cuenta de que · Mapnik no renderiza boundary=protected_area. Ya sabemos que no mapeamos para el Renderer, pero bueno saberlo. · Un problema: un admin_level=7 dentro de un admin_level=6 no es renderizado, cuando no tiene contacto con el polígono exterior. Cuando cruza la “frontera”
Re: [Talk-co] Una propuesta para mapear pueblos indígenas
Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Ok pa'eso estamos, colaborando entonces. Saludos. 2012/6/28 Federico Explorador (Nevados.org) federico.explora...@nevados.org Hola Germán y colegas: Muchas gracias por tu planteamiento, que enriquece la discusión. Comparto con tigo que boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado. Bien podríamos usarlo para los resguardos indígenas, como también para los territorios colectivos de la población afrodescendiente. Sin embargo, me parece que con la afirmación usar boundary=administrative crea más problemas que soluciones ... ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, no estás en lo correcto. Los resguardos indígenas son entidades territoriales o pueden adquirir este status, administrando su territorio con cierta autonomía, de acuerdo a la constitución y las leyes de ordenamiento territorial. Reciben recursos del Estado a través de los municipios e incluso pueden adquirir incluso el estatus de un municipio. (ver documento DNP, [1]). Si propuse usar el valor boundary=administrative, admin_level=7 (un nivel debajo de municipio), era para reconocer a los pueblos indígenas precisamente este derecho de autonomía administrativa en sus territorios. Sí es cierto de que en la mayoría de casos, el territorio municipal y el territorio indígena no colindan, sino se solapan o el último está dentro del otro; así que no hay linderos compartidos. El valor protected area enfoca la protección (de la naturaleza o de un grupo humano) a la cual por cierto los indígenas también tienen derecho (Para los más interesados, hay un link con un ejemplo desde la visión indígena en [2]. Lo malo es que ambos conceptos, el de protección y el de administración, pasan por el tag boundary, así que tenemos que decidirnos por uno de los dos. Para mí está bien trabajar con protected_area, pero quería hacer la aclaración anterior. Lo importante que establezcamos un estándar con el cual podemos generar mapas que visualicen los resguardos. Entonces tendríamos para los resguardos: boundary=protected_area protect_class=24 ethnic_group=* Como en la actualidad muchos resguardos figuran ya en OSM producto de una importación, incluso podría haber una tarea para botica. Los imports vienen, entre otros, con ETNIA=*, entonces botica podría adicionar a todas las entradas con ETNIA=* el valor boundary=protected_area, protect_class=24 y luego sustituir ETNIA por ethnic_group. Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Saludos, Federico [1] http://www.dnp.gov.co/LinkClick.aspx?fileticket=CpCS1dVTQf4%3Dtabid=273 [2] Ejemplo desde la visión indígena (wayúu): http://www.unisi.it/cisai/wayuu.htm -Mensaje original- De: Germán Márquez Mejía [mailto:manch...@gmail.com] Enviado el: jueves, 28 de junio de 2012 09:52 a.m. Para: OpenStreetMap Colombia Asunto: Re: [Talk-co] Una propuesta para mapear pueblos indígenas No soy partdario de usar boundary=administrative. Crea más problemas que soluciones e interfiere con el esquema que tenemos, ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, de manera que puede darse el caso de un resguardo con partes de su territorio en varios municipios y problemas con la distorsión de la extensión real de los corregimientos. boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado y elaborado (por algo fue aceptado). Con boundary=protected_area basta y sobra y, si se ve o no en Mapnik, como lo han dicho, no es argumento para desecharlo o para meterle etiquetas que no corresponden (administrative). Al fin y al cabo, con el renderer colombiano se pueden hacer visibles en el futuro, o ahora, con una capa Vector en OL. Así que propongo no mezclar peras con manzanas y usar solo boundary=protected_area. Am Mittwoch, den 27.06.2012, 23:32 -0500 schrieb Federico Explorador (Nevados.org): Para responder más cosas a Edwin y a mí mismo: Probando, me he dado cuenta de que · Mapnik no renderiza boundary=protected_area. Ya sabemos que no mapeamos para el Renderer, pero bueno saberlo. · Un problema: un admin_level=7 dentro de un admin_level=6 no es renderizado, cuando no tiene contacto con el polígono exterior. Cuando cruza la “frontera” al otro lado, no hay problema, es renderizado, ver http://www.openstreetmap.org/?lat=2.47183lon=-76.47727zoom=15layers=MEn la misma zona hay otros 2 resguardos “invisibles”, mapeado
Re: [Talk-co] Una propuesta para mapear pueblos indígenas
Hola, yo estoy viviendo en Iza, Boyacá, y se he ido observando un proceso muy interesante de muchas comunidades que se están autoreconociendo como Muiscas en el contexto del Cabildo Muisca de Boyacá, aparte de las comunidades Muiscas que ya se han identificado como tal en el Departamento. Estoy muy comunicado con el Gobernador del Cabildo Muisca en Tunja, y el me puede suministrar mucha información respecto a la distribución regional de estas comunidades. Quedo de Uds. Bennet Campoverde, Geógrafo / Reconocedor Predial IGAC Date: Fri, 29 Jun 2012 13:53:55 -0500 From: edy...@gmail.com To: talk-co@openstreetmap.org Subject: Re: [Talk-co] Una propuesta para mapear pueblos indígenas Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Ok pa'eso estamos, colaborando entonces. Saludos. 2012/6/28 Federico Explorador (Nevados.org) federico.explora...@nevados.org Hola Germán y colegas: Muchas gracias por tu planteamiento, que enriquece la discusión. Comparto con tigo que boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado. Bien podríamos usarlo para los resguardos indígenas, como también para los territorios colectivos de la población afrodescendiente. Sin embargo, me parece que con la afirmación usar boundary=administrative crea más problemas que soluciones ... ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, no estás en lo correcto. Los resguardos indígenas son entidades territoriales o pueden adquirir este status, administrando su territorio con cierta autonomía, de acuerdo a la constitución y las leyes de ordenamiento territorial. Reciben recursos del Estado a través de los municipios e incluso pueden adquirir incluso el estatus de un municipio. (ver documento DNP, [1]). Si propuse usar el valor boundary=administrative, admin_level=7 (un nivel debajo de municipio), era para reconocer a los pueblos indígenas precisamente este derecho de autonomía administrativa en sus territorios. Sí es cierto de que en la mayoría de casos, el territorio municipal y el territorio indígena no colindan, sino se solapan o el último está dentro del otro; así que no hay linderos compartidos. El valor protected area enfoca la protección (de la naturaleza o de un grupo humano) a la cual por cierto los indígenas también tienen derecho (Para los más interesados, hay un link con un ejemplo desde la visión indígena en [2]. Lo malo es que ambos conceptos, el de protección y el de administración, pasan por el tag boundary, así que tenemos que decidirnos por uno de los dos. Para mí está bien trabajar con protected_area, pero quería hacer la aclaración anterior. Lo importante que establezcamos un estándar con el cual podemos generar mapas que visualicen los resguardos. Entonces tendríamos para los resguardos: boundary=protected_area protect_class=24 ethnic_group=* Como en la actualidad muchos resguardos figuran ya en OSM producto de una importación, incluso podría haber una tarea para botica. Los imports vienen, entre otros, con ETNIA=*, entonces botica podría adicionar a todas las entradas con ETNIA=* el valor boundary=protected_area, protect_class=24 y luego sustituir ETNIA por ethnic_group. Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Saludos, Federico [1] http://www.dnp.gov.co/LinkClick.aspx?fileticket=CpCS1dVTQf4%3Dtabid=273 [2] Ejemplo desde la visión indígena (wayúu): http://www.unisi.it/cisai/wayuu.htm -Mensaje original- De: Germán Márquez Mejía [mailto:manch...@gmail.com] Enviado el: jueves, 28 de junio de 2012 09:52 a.m. Para: OpenStreetMap Colombia Asunto: Re: [Talk-co] Una propuesta para mapear pueblos indígenas No soy partdario de usar boundary=administrative. Crea más problemas que soluciones e interfiere con el esquema que tenemos, ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, de manera que puede darse el caso de un resguardo con partes de su territorio en varios municipios y problemas con la distorsión de la extensión real de los corregimientos. boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado y elaborado (por algo fue aceptado). Con boundary=protected_area basta y sobra y, si se ve o no en Mapnik, como lo han dicho, no es argumento para desecharlo o para meterle etiquetas que no corresponden (administrative). Al fin y al cabo, con el renderer colombiano se pueden hacer visibles en el futuro, o ahora, con una capa Vector en OL. Así que propongo no mezclar peras con
Re: [Talk-co] Una propuesta para mapear pueblos indígenas
Muy bien, ver mis comentarios dentro del texto! -Mensaje original- De: Germán Márquez Mejía [mailto:manch...@gmail.com] Enviado el: viernes, 29 de junio de 2012 08:25 a.m. Para: talk-co@openstreetmap.org Asunto: Re: [Talk-co] Una propuesta para mapear pueblos indígenas Listo, tarea perfecta para Botika. @Federico: podrías agregar Colombia a la tabla en la página del wiki de protected_area [0] y hacer esa salvedad. HECHO!, VER [0] Después en el renderer podemos hacerlo parecido a los límites administrativos. EXCELENTE, propongo una apariencia parecida a parques nacionales, pero en vez de un tenue fondo verde, un ténue fondo rojo, con el nombre del resguardo en un tamaño entre village y town (tomando como referencia Mapnik) y un color de letra café. Yo me ofrezco a ir por la parte del Chocó, si no hay alguien que conozca mejor la zona. YO VOY POR CÓRDOBA, SIERRA NEVADA Y NORORIENTE [0] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area Am Donnerstag, den 28.06.2012, 18:05 -0500 schrieb Federico Explorador (Nevados.org): Hola Germán y colegas: Muchas gracias por tu planteamiento, que enriquece la discusión. Comparto con tigo que boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado. Bien podríamos usarlo para los resguardos indígenas, como también para los territorios colectivos de la población afrodescendiente. Sin embargo, me parece que con la afirmación usar boundary=administrative crea más problemas que soluciones ... ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, no estás en lo correcto. Los resguardos indígenas son entidades territoriales o pueden adquirir este status, administrando su territorio con cierta autonomía, de acuerdo a la constitución y las leyes de ordenamiento territorial. Reciben recursos del Estado a través de los municipios e incluso pueden adquirir incluso el estatus de un municipio. (ver documento DNP, [1]). Si propuse usar el valor boundary=administrative, admin_level=7 (un nivel debajo de municipio), era para reconocer a los pueblos indígenas precisamente este derecho de autonomía administrativa en sus territorios. Sí es cierto de que en la mayoría de casos, el territorio municipal y el territorio indígena no colindan, sino se solapan o el último está dentro del otro; así que no hay linderos compartidos. El valor protected area enfoca la protección (de la naturaleza o de un grupo humano) a la cual por cierto los indígenas también tienen derecho (Para los más interesados, hay un link con un ejemplo desde la visión indígena en [2]. Lo malo es que ambos conceptos, el de protección y el de administración, pasan por el tag boundary, así que tenemos que decidirnos por uno de los dos. Para mí está bien trabajar con protected_area, pero quería hacer la aclaración anterior. Lo importante que establezcamos un estándar con el cual podemos generar mapas que visualicen los resguardos. Entonces tendríamos para los resguardos: boundary=protected_area protect_class=24 ethnic_group=* Como en la actualidad muchos resguardos figuran ya en OSM producto de una importación, incluso podría haber una tarea para botica. Los imports vienen, entre otros, con ETNIA=*, entonces botica podría adicionar a todas las entradas con ETNIA=* el valor boundary=protected_area, protect_class=24 y luego sustituir ETNIA por ethnic_group. Luego, con Humberto en la Costa, Edwin en el Cauca, yo por el Nororiente y otros que se quieran sumar a la causa podríamos ir completando el mapa. Saludos, Federico [1] http://www.dnp.gov.co/LinkClick.aspx?fileticket=CpCS1dVTQf4%3Dtabid=2 73 [2] Ejemplo desde la visión indígena (wayúu): http://www.unisi.it/cisai/wayuu.htm -Mensaje original- De: Germán Márquez Mejía [mailto:manch...@gmail.com] Enviado el: jueves, 28 de junio de 2012 09:52 a.m. Para: OpenStreetMap Colombia Asunto: Re: [Talk-co] Una propuesta para mapear pueblos indígenas No soy partdario de usar boundary=administrative. Crea más problemas que soluciones e interfiere con el esquema que tenemos, ya que estos territorios son ancestrales y completamente independientes de la división político-administrativa actual, de manera que puede darse el caso de un resguardo con partes de su territorio en varios municipios y problemas con la distorsión de la extensión real de los corregimientos. boundary=protected_area no es un esquema suplementario, sino todo un sistema en sí mismo y, por lo que veo, está muy bien pensado y elaborado (por algo fue aceptado). Con boundary=protected_area basta y sobra y, si se ve o no en Mapnik, como lo han dicho, no es argumento para desecharlo o para meterle etiquetas que no corresponden (administrative). Al fin y al cabo, con el
Re: [Talk-dk] åbne offentlige datalicens + osm
2012/6/28 Morten Kjeldgaard m...@bioxray.dk: den attribution side på Wiki'en Michael henviser til er ikke-eksisterende. Bare fjern det overskydende punktum: http://wiki.openstreetmap.org/wiki/Attribution /Lars ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-se] Taggning av kalhyggen
Ok, det kan jag testa. Hur gör man med kraftledningsgator i skogen? Mvh Christian 2012-06-28 21:04, Erik Johansson skrev: Det kan bli skog av kalhyggen väldigt fort, men som du säger man ser ju att det varit slutavverkning länge. Det länkas till scrub från forrest wiki sidan, så kanske något sådant här: landuse=forest date_kalhygge=2012 date_clearcut=2012 natural=scrub http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub 2012/6/26 Christian Asker christian.as...@gmail.com: Hej igen. Jag har ytterligare en fråga som jag inte kan hitta information om. Hur bör jag tagga kalhyggen? Nyare hyggen har ju inte mycket träd, så skog känns ju inte rätt. Äldre hyggen är ju nästan skog, fast ändå inte. Jag vill ju helst att det ska synas på kartan ifall det är skog eller kalhygge. Mvh Christian ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-ar] Mapa compilado para Garmin
El jue, 28-06-2012 a las 19:26 -0300, Werner Horsch escribió: podriamos volcar esto al foro, q título le ponemos, Gimenez's map? Te dejo el honor de crear tu propio post Martin, vale la pena además de tener la info más ordenada Usemos el que creó Pertile: http://forum.openstreetmap.org/viewtopic.php?id=17139 Tal vez se pueda modificar el primer post para incluír algo de info sobre el mapa. Lo estuve usando en mi Nüvi 1) Habría q modificar el contraste para q se vea mejor, las calles residenciales casi no se ven. Las residenciales casi no se destinguen del fondo, las otras se ven pero cuestan un poco. Podrías probar con colores más oscuros para las calles o con un color diferente para el fondo. O tal vez un contorno a la calle para evitar el problema cuando cambias de diurno a nocturno Acepto la sugerencia y estoy modificando el TYP para que tenga algo mas de contraste en los contornos que delimitan las calles. 2) CABA figura en inglés Autonomous City., no sé si alguién lo cambio en osm, hay q investigar. si no lo escribo en inglés no aparece la ciudad en busquedas Eso hay que verlo en OSM, creeria que proviene de allí el problema. 3) El tema de la busqueda sigue siendo nuestro problema, hay q ver q opción ususaste al compilar si uniste o no las calles para q funcione la busqueda por intersección de calles. En CABA no me funciono la busqueda por cruce en un pueblo chico si. probablemente pq las calles estén cortadas por cambios de mano o rest de giro Lo bueno es q aparece una única vez cada calle A mí no me funciona tampoco, probé hacerlo en General Las Heras y nada. Los scripts de creación están publicados en: http://download.i-nis.com.ar/openstreetmap/mapas/garmin/scripts/ Es muy importante solucionar el tema de la búsqueda por intersección de las calles, y tenemos que poner esfuerzo en ello. Le doy mi voto a favor Gracias! Saludos, -- Martin Andres Gomez Gimenez web: http://www.i-nis.com.ar e-mail: mggime...@i-nis.com.ar Jabber: mggime...@i-nis.com.ar Usuario Linux: #306000 signature.asc Description: This is a digitally signed message part ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
[Talk-at] OGD Wien Phase 6
Die neuen OGD Wien Datensätze sind gerade online gegangen: http://data.wien.gv.at/neuigkeiten/changelog/liste-phase6.html Neu ist vor allem der Flächenwidmungsplan, die Denkmalstandorte und das Ubahn Netz. cu andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] FWD: Open Government Graz Round Table - MI, 11.7.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Habe eben eine Einladung zum Open Government Graz Round Table bekommen, die möchte ich gerne weiterleiten! Ich selbst bin zu dem Zeitpunkt leider nicht im Lande, aber ich würde mich freuen, wenn andere engagierte Grazer dort hinschauen würden und im Sinne von OSM dort mitdiskutieren! Vor allem würden wir uns um Hausnummern etc. im Vektorformat freuen :-) lg, Michi Einladung von Daniela Grabe == Sehr geehrte Damen und Herren, liebe Kolleginnen und Kollegen, wie Sie ja wissen/ihr ja wisst, hat die Stadt Graz mit einem Gemeinderatsbeschluss im Frühjahr diesen Jahres über die städtische ITG Informationstechnik Graz GmbH ein mehrstufiges Open Government Data-Projekt gestartet, und vorige Woche ist ja auch bereits die erste Tranche an Open Government-Daten veröffentlicht worden. Nun möchten wir - ganz im Sinne dieser Openness (und wie auch im Umsetzungskonzept des Projekts verankert) - mit der Einrichtung von Round Tables bzw. mit weiteren Maßnahmen zur Verbreitung und Nutzung der OGD-Daten beginnen, um gemeinsam mit BürgerInnen, Fachleuten, EntwicklerInnen und anderen Stake Holdern Ideen und Vorschläge zur Verbreitung und Bewerbung, für Kooperationen mit der IT-Szene, Wirtschaft, Kulturschaffenden und Magistratsabteilungen/städtischen Bereichen zu entwickeln. Daher laden wir herzlich ein zu einem ersten Treffen: MI, 11.7., 16:30-ca. 19:00, direkt bei der ITG; Schmiedgasse/Amtshaus, 4. Stock Geplante Inhalte: Diskussion, was wir von Beispielen aus anderen Städten ev. auch übernehmen bzw. anregen sollten wie auch die FH-Studiengänge Journalismus und Informationsdesign dabei unterstützend tätig werden könnten: z.B. gemeinsame Wettbewerbausschreibung für die interessantesten Apps in verschiedenen Kategorien, z.B. Einführung regelmäßiger offener Runden mit involvierten (oder noch zu involvierenden/interessierenden)Playern in der Stadtverwaltung und aus an Open Government interessierten BürgerInnen, Wirtschaftstreibenden, IT-Leuten... welche weiteren Schritte für die Bekanntmachung, Nutzung, Verbreitung der Daten sinnvoll wären was für die nächsten Phasen der Datenaufbereitung angedacht ist Wir freuen uns auf Ihre/eure Teilnahme Barbara Meyer (ITG) Julian Ausserhofer und Heinz Wittenbrink (FH JOANNEUM ) Daniela Grabe, Peter Mayr (Gemeinderat) Gemeinderätin Mag.a DI (FH) Daniela Grabe Grüner Gemeinderatsklub 8010 Rathaus T: 0316/872-2163 (Sekretariat) - -- Michael Maier, Student of Telematics @ Graz University of Technology -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP7XFcAAoJEPDJmZ2oE4mGyDYP/2rIe4AuKzEDxZZ/w8IaUHFy HZQFIWiiLz2SH5NhP0Rruz/O6399TvduSNto7lLH1fiM2NK6JH3VmLymwXjjnEX8 HeMGDzpLSu19oWB5Lr5PfnaHXFGzWI4qa0Afr+IuM5+ma0gOGSj/vSYLq3fVex72 C6CuCRiZWkhuCqNvyIQCZjfOmhQfBczgxMA4hZ94EkW071M9hM2rIcGlwOM6V0L7 EKCLa2n4ksrNElqgjjorFn8hAcVsYDb9kSikOHntoKglcswxFKk8mHoTCrY+FWmO S4dgbaKfAkUFTZi+2g5dWArScnwFzYTzqwDvDij7g/A3VtI/alDZhwC9hSSgTAso WkDcmdD61C2TBeiAXzcKxizBA6Xn8BtNjCfmlxBlBIaTUDDcc8UXeQ5fJpdUITXu cE7dUEV9C96QtOS6lWFnlFLleVe/poQoDZZZSikzkVHWv9rb54mzORJTQIMZugah NIY/riKkFzQ/GDIFVOktyaEUxuhJarjs3r3KrjRNT48oQP0FxF57XVJdiM5P0qvB nxV8lZxsCFGTUt2GXbRtoaAkXMivuJkDIrGEUIHH/StCQkXwneyWtErhdKz2m8gp eoEEfq/aieBTZzUe7YSHc72jB3noC7VpvqcBRh/nJDMIywcyvWyWKVzdbu5NIgh5 TUGA5ta3wP6gg6gRRuqR =y1NX -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Wien Phase 6
Am Fr, 29.06.2012, 10:48, schrieb Andreas Trawoeger: Die neuen OGD Wien Datensätze sind gerade online gegangen: http://data.wien.gv.at/neuigkeiten/changelog/liste-phase6.html Neu ist vor allem der Flächenwidmungsplan, die Denkmalstandorte und das Ubahn Netz. cu andreas Frage am Rande: gibt's das auch für/von Linz/Wels/Oberösterreich? (OGD-Daten allgemein für OSM außer Geoimage.at) cu Günther ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Wien Phase 6
Am 29. Juni 2012 11:21 schrieb Günther Zin. o...@fh15.homeip.net: Am Fr, 29.06.2012, 10:48, schrieb Andreas Trawoeger: Die neuen OGD Wien Datensätze sind gerade online gegangen: http://data.wien.gv.at/neuigkeiten/changelog/liste-phase6.html Frage am Rande: gibt's das auch für/von Linz/Wels/Oberösterreich? (OGD-Daten allgemein für OSM außer Geoimage.at) Für Linz sind aktuell die Orthophotos, der Stadtplan und die Höhenschichtlinien verfügbar http://data.linz.gv.at/daten/Geodaten Nachdem Stadt Linz die Daten nur in der Gauß-Krüger Projektion anbietet, gibt es von mir einen inoffizellen TMS Server der die Daten transformiert: http://tms.kartenwerkstatt.at/demo/ cu andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Wien Phase 6
Speziell das U-Bahn Netz ist interessant (da gibt es ja bei den
unterirdischen Bereichen noch ein wenig zu verbessern).
Hab jetzt mal die Daten mit wms[1] eingebunden, warum auch immer haben
sie noch einen Versatz. Mit geoimage.at und dem Aktuellen Datenbestand
bin ich durch verschieben (jeweils im Norden, Süden, Osten und Westen
mal schnell kontrolliert) auf folgendes gekommen:
-133.50; -78.00
Wenn keiner Einwände hat, würde ich das U-Bahn Netz in OSM anhand dieser
Daten erweitern.
LG Jimmy
[1]
wms:http://data.wien.gv.at/daten/wms?request=GetMapversion=1.1.1width={width}height={height}layers=UBAHNOGD,UBAHNHALTOGDstyles=format=image/gifbbox={bbox}SRS={proj}
Am 29.06.2012 10:48, schrieb Andreas Trawoeger:
Die neuen OGD Wien Datensätze sind gerade online gegangen:
http://data.wien.gv.at/neuigkeiten/changelog/liste-phase6.html
Neu ist vor allem der Flächenwidmungsplan, die Denkmalstandorte und
das Ubahn Netz.
cu andreas
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Wien Phase 6
Die *.kml heruntergeladen, mit opendata importiert und schon ist das
Problem behoben. Sry, für Spam!
Am 29.06.2012 15:33, schrieb Jimmy_K:
Speziell das U-Bahn Netz ist interessant (da gibt es ja bei den
unterirdischen Bereichen noch ein wenig zu verbessern).
Hab jetzt mal die Daten mit wms[1] eingebunden, warum auch immer haben
sie noch einen Versatz. Mit geoimage.at und dem Aktuellen Datenbestand
bin ich durch verschieben (jeweils im Norden, Süden, Osten und Westen
mal schnell kontrolliert) auf folgendes gekommen:
-133.50; -78.00
Wenn keiner Einwände hat, würde ich das U-Bahn Netz in OSM anhand dieser
Daten erweitern.
LG Jimmy
[1]
wms:http://data.wien.gv.at/daten/wms?request=GetMapversion=1.1.1width={width}height={height}layers=UBAHNOGD,UBAHNHALTOGDstyles=format=image/gifbbox={bbox}SRS={proj}
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
Andreas Uller schrieb: Im Zweifelsfall lasse ich die Straße aber auch wie Christian im landuse-mäßigen Niemandsland - auch auf das Risiko hin dass der Renderer die Straße dann schmäler zeichnet als sie tatsächlich ist und ein grauer Hintergrund erscheint. Da stimme ich zu, schließlich ist das kein Niemandsland sondern die wirkliche Fläche der Straße. Mit korrekt angegebener width und einem Renderer, der dieses Tag nutzt, würde diese Fläche auch beim Rendern immer von der Straße ausgefüllt. Wir malen keine Bilder, sondern erstellen eine Datenbank mit Abstraktionen, die in verschiedener Weise, u.a. gezeichneten Karten, verwendbar sind. Robert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
On 29.06.2012 21:01, Robert Kaiser wrote: Andreas Uller schrieb: Im Zweifelsfall lasse ich die Straße aber auch wie Christian im landuse-mäßigen Niemandsland - auch auf das Risiko hin dass der Renderer die Straße dann schmäler zeichnet als sie tatsächlich ist und ein grauer Hintergrund erscheint. Da stimme ich zu, schließlich ist das kein Niemandsland sondern die wirkliche Fläche der Straße. Diese Fläche wird in OSM aber nicht erfasst. Daher doch Niemandsland. Mit korrekt angegebener width und einem Renderer, der dieses Tag nutzt, würde diese Fläche auch beim Rendern immer von der Straße ausgefüllt. So genau kannst du gar nicht zeichnen, dass die Landuses überall genau width/2 Abstand von der Straße haben. Es ist sogar mathematisch unmöglich (width ist rationale Zahl, Abstand zwischen 2 Nodes ist i.a. irrationale Zahl). Geometrisch ist es ebenfalls unmöglich (in Kurven ist der Abstand eines Polygonzugs immer größer als dazwischen). Und zu allem Überdruss wär das eine doppelt redundante Datenerfassung (width=*, Abstand auf der einen Seite, Abstand auf der anderen Seite). Wir malen keine Bilder, sondern erstellen eine Datenbank mit Abstraktionen, die in verschiedener Weise, u.a. gezeichneten Karten, verwendbar sind. Das spricht genau gegen das, was du zuvor geschrieben hast. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
Friedrich Volkmann schrieb: So genau kannst du gar nicht zeichnen, dass die Landuses überall genau width/2 Abstand von der Straße haben ... Das spricht genau gegen das, was du zuvor geschrieben hast. Ich hab ca. 4000 ungelesene E-Mails aus den letzten 2 Wochen Urlaub, ich hab keine Lust, Diskussionen zu führen, die nur auf die Pingeligkeit von rationalen oder irrationalen Zahlen in der mathematischen Theorie rauslaufen. Tatsache ist, dass unsere DB ein Modell ist und nicht mathematisch genau sein braucht. Ich halte alles, was genauer als 5m ist, als höchstwahrscheinlich sinnlos in unserem Modell, wenn man will, kann man bis 1m runter, aber was weniger als das ist, ist wirklich in unserem Modell nicht sinnvoll. Zwischen Flächen- und Vektormapping gibt es natürlich einen Kompromiss, und der ist oft nicht 100% klar definierbar. Grundsätzlich sollten Flächen IMHO so getaggt werden, als würden wir Straßen als Flächen mappen - aber trotzdem die Straße als Vektor belassen. Ergo, es bleibt im Denken von Flächenmalern ein Niemandsland. In unserem Modell ist das durchaus OK und richtig. Robert Kaiser ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wienerwald (relation 305434)
On 29.06.12 22:14, Friedrich Volkmann wrote: Diese Fläche wird in OSM aber nicht erfasst. Daher doch Niemandsland. Es gab schon mal Diskussionen über einen landuse=Verkehrsfläche. Sowas machte z.B. bei Autobahnen vielleicht Sinn... Aber nur zwei Gedanken dazu: Es gibt Flächennutzungsklassendatenbanken. Da wird meist das Land in kleine Quadrate geteilt und jede Fläche mit einer Nutzungsklasse (und einer Höhe) versehen. Sowas verwenden zB die Mobilfunker für Ausbreitungsrechnungen (um entscheiden zu können, wo sie denn am besten ihre Masten hinstellen). - OSM will so etwas (zumindest bin ich fest davon überzeugt) /nicht/ sein. Ich habe an anderer Stelle (beim gleichen Thema) schon mal vom Mut zur Lücke gesprochen. Wir erfassen Flächen wegen ihrer kartographischen/geographischen Bedeutung (zur Orientierung o.ä.; aber keine Flächennutzungsklasseneinteilung). Und es gibt halt auch schon mal Flächen, die eben weiß sind. Und der zweite ist die Ambivalenz: einerseits wollen wir einen Verkehrsgraphen (für Navigationsaufgaben genauso wie zum Rendern), andererseits wollen wir wichtige Flächen eben auch. Das führt eben zu solchen von Dir Niemandsland genannten Situationen und die sind bewußt in Kauf genommen/auch nicht schlimm. Das ist eben gewollt so. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec...
Je fais suivre le courriel de Nicolas Gignac adressé à la liste OSGeo-qc concernant le nouveau site de données ouvertes du gouvernement du Québec. Nous ne retrouvons pas les données de limites administratives (ville, MRC, régions administratives). Pourquoi ne pas les demander? I forward the email sent to the OSGeo-qc list byNicolas Gignac relatively to the Government of Québec Open Data site newly created. We do not find the administrative boundaries data (city, RCM, administrative region). Why not ask? Pierre - Mail transféré - De : Nicolas Gignac gignac...@gmail.com À : OSGeo-Quebec que...@lists.osgeo.org Envoyé le : Vendredi 29 juin 2012 15h17 Objet : [OSGeo-qc] Données ouvertes : gouvernement du Québec... Pour votre info, le site de données ouvertes du gouvernement du Québec est maintenant officiellement en ligne depuis hier : http://donnees.gouv.qc.ca La partie géomatique du site : http://donnees.gouv.qc.ca/?node=/applications-geomatique est supportée par le projet GOLOC qui intègre OpenLayers / GeoExt et les couches WMS sont diffusées par UMN MapServer. Des données brutes sont également disponibles en format Shapefile et KML. L'url du getcapabilities pour le WMS qui inclue certaines des données ouvertes géographiques est le suivant : http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc?request=getcapabilitiesservice=wmsversion=1.1.1 Le site web en tant que tel est supporté par du code en JQuery / Php, avec un service de catalogue normé (Catalog Service for the Web) : http://en.wikipedia.org/wiki/Catalog_Service_for_the_Web supporté par le projet international GeoNetwork (http://geonetwork-opensource.org/), une base de données PostgreSQL (www.postgresql.org/) et ses fonctionnalités PG de full text searching comme tsvector et trigram pour la recherche du catalogue, tout cela est monté sur deux serveurs Linux : OpenSuse et Ubuntu Server ( pour GeoNetwork). Si vous avez des données géographiques que vous aimeriez voir sur le site de données ouvertes produites par le gouvernement du Québec et qu'elles ne s'y retrouvent pas, veuillez faire une demande de données en utilisant le formulaire disponible en ligne sur le site : http://donnees.gouv.qc.ca/?node=/demande-donnees Au plaisir, Nicolas ___ Quebec mailing list que...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/quebec ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec...
Pour votre info, il y a des données géographiques administratives sur le site de données ouvertes du Qc, voir ce jeu de données : http://donnees.gouv.qc.ca/?node=/donnees-detailsid=d6c535cb-b508-4cab-9a15-bdccd9433da4 Sur la page de téléchargement, voir la section *Découpages administratifs**(mise à jour mai 2012) * : http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp Évidemment, l'échelle de cette donnée est au 1 : 1 000 000. Au plaisir, Nicolas Le 29 juin 2012 16:50, Pierre Béland infosbelas-...@yahoo.fr a écrit : Je fais suivre le courriel de Nicolas Gignac adressé à la liste OSGeo-qc concernant le nouveau site de données ouvertes du gouvernement du Québec. Nous ne retrouvons pas les données de limites administratives (ville, MRC, régions administratives). Pourquoi ne pas les demander? I forward the email sent to the OSGeo-qc list by Nicolas Gignac relatively to the Government of Québec Open Data site newly created. We do not find the administrative boundaries data (city, RCM, administrative region). Why not ask? Pierre - Mail transféré - *De :* Nicolas Gignac gignac...@gmail.com *À :* OSGeo-Quebec que...@lists.osgeo.org *Envoyé le :* Vendredi 29 juin 2012 15h17 *Objet :* [OSGeo-qc] Données ouvertes : gouvernement du Québec... Pour votre info, le site de données ouvertes du gouvernement du Québec est maintenant officiellement en ligne depuis hier : http://donnees.gouv.qc.ca La partie géomatique du site : http://donnees.gouv.qc.ca/?node=/applications-geomatique est supportée par le projet GOLOC qui intègre OpenLayers / GeoExt et les couches WMS sont diffusées par UMN MapServer http://mapserver.org/. Des données brutes sont également disponibles en format Shapefile et KML. L'url du getcapabilities pour le WMS qui inclue certaines des données ouvertes géographiques est le suivant : http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc?request=getcapabilitiesservice=wmsversion=1.1.1 Le site web en tant que tel est supporté par du code en JQuery / Php, avec un service de catalogue normé (Catalog Service for the Web) : http://en.wikipedia.org/wiki/Catalog_Service_for_the_Web supporté par le projet international GeoNetwork (http://geonetwork-opensource.org/), une base de données PostgreSQL (www.postgresql.org/) et ses fonctionnalités PG de full text searching comme tsvector et trigram pour la recherche du catalogue, tout cela est monté sur deux serveurs Linux : OpenSuse et Ubuntu Server ( pour GeoNetwork). Si vous avez des données géographiques que vous aimeriez voir sur le site de données ouvertes produites par le gouvernement du Québec et qu'elles ne s'y retrouvent pas, veuillez faire une demande de données en utilisant le formulaire disponible en ligne sur le site : http://donnees.gouv.qc.ca/?node=/demande-donnees Au plaisir, Nicolas ___ Quebec mailing list que...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/quebec ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] zoom sur carte
Le vendredi 29 juin 2012 à 06:21 +0200, Philippe Verdy a écrit : Le 28 juin 2012 08:37, Marc Sibert m...@sibert.fr a écrit : http://c.tile.openstreetmap.org/18/133039/90247.png/status (donne l'état de la tuile) http://c.tile.openstreetmap.org/18/133039/90247.png/dirty (force le refresh) Dommage qu'on n'ait pas la même chose (au moins la sous-page /status) sur les autres serveurs de tuiles hors ceux ici de Mapnik. (C'est mod_tile qui fournit ceci. Mapnik est le moteur de rendu, pas le serveur). De même le framework OpenLayers ne tient pas compte de l'état du cache web affiche de façon indéfinie des images obsolètes récupérées d'anciennes versions stockées dans le cache, même lorsque le navigateur a chargé une nouvelle version des tuiles. [...] Les tuiles ne sont en fait que des images et OpenLayers les chargent comme telles. Comme tu le dis, OpenLayers ne tient pas compte de l'état du cache, il ne s'en occupe effectivement pas du tout. La gestion du cache que tu critiques est en fait celle du navigateur et concerne toutes les images, tuiles ou autres. Note qu'il serait difficile pour OpenLayers d'imposer arbitrairement une gestion du cache puisque toutes les couches tuilées ne sont pas identiques. Une couche basée sur des données VMAP ne change jamais alors qu'une couche basée sur OSM est très régulièrement mise à jour par exemple. Il existe des astuces pour éviter la mise en cache des ressources (images ou autre) mais c'est au développeur de l'application de les mettre en œuvre en fonction des besoins et des spécificités de ses tuiles. Au moins on n'a pas ce problème de rafraîchissement avec les autres frameworks. Mais OpenLayers est une collection de scripts particulièrement complexes qui génère du code Javascript effectuant apparemment ses requêtes HTTP lui-même sans passer par les fonctions de chargement web du navigateur OpenLayers construit dynamiquement l'URL des tuiles (des images donc) et ensuite ajoute un element img dans le DOM avec l'URL de la tuile comme source. C'est la procédure habituelle pour insérer dynamiquement une image dans une page et c'est, à mon humble connaissance, de cette manière que les autres framework fonctionnent aussi. et gérant d'une façon étrange le stockage dans le cache (ou qui ne tient pas compte des dates d'obsolescence): il génère alors un cache local absolument énorme contenant des tonnes de tuiles obsolètes qui ne sont même pas purgées. Encore une fois, le cache est géré par le navigateur, pas par OpenLayers. Si tu penses que la taille du cache devient trop importante, libre à toi de configurer ton navigateur en réduisant la taille de son cache. -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 29 juin 2012 10:46, Gilles Bassière gbassi...@gmail.com a écrit : OpenLayers construit dynamiquement l'URL des tuiles (des images donc) et ensuite ajoute un element img dans le DOM avec l'URL de la tuile comme source. C'est la procédure habituelle pour insérer dynamiquement une image dans une page et c'est, à mon humble connaissance, de cette manière que les autres framework fonctionnent aussi. Visiblement il ne fonctionne pas du tout comme ça, il forme des requêtes dynamiques en Javascriptn et réimplémente dans ce script même le protocole HTTP lui-même, et utilise ses propres fonctions pour inscrire des ressources dans le cache. Ce serait tellement simple s'il se contentait de créer des balises img dans la page HTML en leur indiquant la source, mais visiblement il y a toute une usine derrière et le comportement réseau (tel que vu depuis la console du navigateur) est finalement extrêmement complexe (au passage il cherche aussi à utiliser des extensions Google assez récentes et pas encore normalisées, de fait ce n'est plus du HTTP classique, même si cela marche avec des serveurs HTTP classiques). Tout ça pour dire qu'il n'utilise pas la fonction de téléchargement de resource du navigateur mais la réimplante entièrement (je le vois créer lui-même des sockets, construire les cookies, les entêtes MIME). Et en fin de compte je me retrouve avec le cache du navigateur qui contient toute une série de versions de la même image chargées à différentes dates, mais dont OpenLayers continue à n'utiliser QUE la plus ancienne au lieu de prendre la plus récente et nettoyer les anciennes versions. A mon avis c'est un paquet de gros bogues dans les javascripts d'OpenLayers. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 29 juin 2012 10:46, Gilles Bassière gbassi...@gmail.com a écrit : Encore une fois, le cache est géré par le navigateur, pas par OpenLayers. Si tu penses que la taille du cache devient trop importante, libre à toi de configurer ton navigateur en réduisant la taille de son cache. S'il utilisait le cache du navigateur, ces images en excès seraient nettoyées. Ce n'est pas le cas du tout, il n'est pas tenu compte du tout de la taille maxi du cache dans les préférences du navigateur. OpenLayers remplit...remplit... remplit... dans un dossier du navigateur mais pas dans son cache normal. Et ne nettoie rien du tout. En configurant le cache à 1Go les images téléchargées par OpenLayers arrivent rapidement à des dizaines de gigaoctets, cela grossit sans aucune limite. Si je vide le cache du navigateur par sa fonction intégrée, cela ne supprime pas ces images. Le seul moyen c'est de fermer complètement le navigateur et ses processus en arrière-plan, puis supprimer manuellement son dossier de cache d'application. Visiblement OpenLayers utilise non pas le cache web classique mais un des caches d'application (il y en a plusieurs maintenant selon les protocoles et leur persistence: on connait classiquement le cache des cookies, celui des pages web, il y a celui des bases de données locales, des préférences, des ressources générées dynamiquement, ces dernières semblant être bien celles utilisées par les resources téléchargées par OpenLayers, mais visiblement manipulées avant d'être sauvegardées.) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 29 juin 2012 11:24, Philippe Verdy verd...@wanadoo.fr a écrit : Le 29 juin 2012 10:46, Gilles Bassière gbassi...@gmail.com a écrit : OpenLayers construit dynamiquement l'URL des tuiles (des images donc) et ensuite ajoute un element img dans le DOM avec l'URL de la tuile comme source. C'est la procédure habituelle pour insérer dynamiquement une image dans une page et c'est, à mon humble connaissance, de cette manière que les autres framework fonctionnent aussi. Visiblement il ne fonctionne pas du tout comme ça, il forme des requêtes dynamiques en Javascriptn et réimplémente dans ce script même le protocole HTTP lui-même, et utilise ses propres fonctions pour inscrire des ressources dans le cache. Ce serait tellement simple s'il se contentait de créer des balises img dans la page HTML en leur indiquant la source, mais visiblement il y a toute une usine derrière et le comportement réseau (tel que vu depuis la console du navigateur) est finalement extrêmement complexe (au passage il cherche aussi à utiliser des extensions Google assez récentes et pas encore normalisées, de fait ce n'est plus du HTTP classique, même si cela marche avec des serveurs HTTP classiques). Tout ça pour dire qu'il n'utilise pas la fonction de téléchargement de resource du navigateur mais la réimplante entièrement (je le vois créer lui-même des sockets, construire les cookies, les entêtes MIME). Et en fin de compte je me retrouve avec le cache du navigateur qui contient toute une série de versions de la même image chargées à différentes dates, mais dont OpenLayers continue à n'utiliser QUE la plus ancienne au lieu de prendre la plus récente et nettoyer les anciennes versions. A mon avis c'est un paquet de gros bogues dans les javascripts d'OpenLayers. Bonjour, Tout ça ne sont que des hypothèses sans aucun fondement technique. Si tu n'aimes pas OpenLayers et le Javascript n'en dégoutes pas les autres. Si tu sais comment corriger ce que tu annonces : juste fait le et après parles-en. Enfin, passe sur la liste technique vu la nature de l'échange. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
On 28/06/2012 09:44, Nicolas Dumoulin wrote: je fais une pause sur l'utilisation de la souris, j'ai le bras droit en compote. Fais comme moi - utilises la main gauche. Après une bonne grosse tendinite à la main droite il y a dix ans, due à l'abus de souris, je me suis lancé et après deux semaines j'étais à un niveau opérationnel suffisant. Aujourd'hui je suis entièrement ambidextre à la souris. Ca permet évidemment frimer (essentiel) mais c'est aussi un bon moyen de répartir les efforts sur le deux mains et donc de retarder l'apparition de tendinite. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 29/06/2012 11:24, Philippe Verdy a écrit : il forme des requêtes dynamiques en Javascriptn et *réimplémente* dans ce script même *le protocole HTTP lui-même*, Waow. Openlayers a bien évolué depuis la dernière fois que je l'ai utilisé. M'enfin ils auraient pu implémenter un autre protocole que HTTP, genre SPDY. /ironie -- Tof ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cartopartie Étape du Tour de France
Bonjour, Ce n'est pas annoncé comme étant une cartopartie mais j'y participerai également dans l'objectif de collecter des données tout au long du parcours et en particulier pour les voies vertes... http://www.heureux-cyclage.org/4-6-juillet-2012-Vosges-du-Sud-Une.html Si certains d'entre vous sont motivés pour se joindre à nous, même pour un bout de route, vous êtes les bienvenus! Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
2012/6/29 Jean-Marc Liotier j...@liotier.org: Fais comme moi - utilises la main gauche. Et quand la main gauche flanche à son tour, passe au pied droit, et ainsi de suite ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
