Re: [Talk-hr] Bankomati za OpenStreetMap projekt
Poštovani, ako su vam potrebne bilo kakve dodatne informacije slobodno mi se obratite. Ugodan dan vam želim, Valent Turković. 2010/9/25 Valent Turkovic valent.turko...@gmail.com: Poštovani, obraćam vam se u ime hrvatske podružnice OpenStreetMap projekta koja ima za cilj napraviti slobodnu, otvorenu i besplatnu kartu cijeloga svijeta. Projekt se oslanja potpuno na rad volontera a ideja koja pokreće ovaj projekt je Kada bi svatko kartirao samo svoj kvart vrlo brzo bismo imali kartu cijeloga svijeta. Kako bismo imali što bogatije karte cilj nam je unijeti što više različitih vrsta podataka, imena ulica, škole, bolnice, restorane pa tako i bankomate. Ja osobno kao i ostali volonteri stalno unosimo nove podatke o bankomatima koje vidimo na terenu, no podaci koje unosimo mogu biti sporadični pošto ne znamo gdje se sve nalaze bankomati niti znamo koje smo možda propustili. Ovim putem vas molim da nam dozvolite korištenje vašeg službenog popis bankomata za potrebe OpenStreetMap projekta. OpenStreetMap projekt je neprofitna organizacija no svi podaci koji se unesu u OpenStreetMap bazu podataka mogu se koristiti u neprofitne ali i u komercijalne svrhe. Za detalje o samome projektu možete proučiti službene stranice projekta http://wiki.openstreetmap.org, tamo možete vidjeti kako je ovaj projekt globalan te ima aktivnih volontera iz čitavoga svijeta [1]. Ako vas zanima kako izgleda jedan mapping party pri kojem se prikupljaju podaci pogledajte kratak video prilog [2]. Unaprijed se zahvaljujem na pozitivnim odgovoru i za sva dodatna pitanja stojim vam na raspolaganju, Valent Turković. [1] http://wiki.openstreetmap.org/wiki/Mapping_projects [2] http://www.youtube.com/watch?v=MKP4M49BAbI -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[talk-ph] C6
is there already a trace of this road? motorcycles can already pass, as seen on several forums where they discussed this since 2008...still dirt roads on some parts and not yet for cars... would just love to get to see it on Mapsource. I saw the entrance in Bicutan last month where motorcycles enter the road -- --- I explore, therefore I blog. http://www.backpackingphilippines.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] C6
Hi Eugene, It think it's not the whole stretch, but just a portion of it. I saw pictures of the dirt taken my motorcycle riders (and thus expect only track label in OSM). C6 also seem to have no link to Eusebio road then Ejercito to get to the floodway and the map also has something like a subdivision but seems to-scary-to-be-true road network. If there's a link there I could have taken the route to get to Quezon avenue in taguig rather than C5-east service road- paulino santos. I would love to pass by one of these days. I'm searching for an old lighthouse in Napindan to explore in the future. thanks --- I explore, therefore I blog. http://www.backpackingphilippines.com On Mon, Oct 11, 2010 at 7:52 PM, Eugene Alvin Villar sea...@gmail.comwrote: You mean this? http://osm.org/go/4zhDbNC6-- The whole stretch up to the Taguig-Taytay boundary is already in OSM for some time now. :-) On Mon, Oct 11, 2010 at 6:19 PM, tutubi tut...@backpackingphilippines.com wrote: is there already a trace of this road? motorcycles can already pass, as seen on several forums where they discussed this since 2008...still dirt roads on some parts and not yet for cars... ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Digital Topographic Mapping of Mindanao
Found this news on Sorbi's news blog: http://www.geomanila.com/2010/09/digital-topographic-mapping-of-mindanao.html Finally, our half-a-century old topo maps will be updated. -- 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-be] Monav navigation
Hello, Somebody tried this one ?? http://wiki.openstreetmap.org/wiki/MoNav Marc -- What's on Shortwave guide: choose an hour, go! http://shortwave.tk 700+ Radio Stations on SW http://swstations.tk 300+ languages on SW http://radiolanguages.tk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] busroutes
Je opmerking over verkorte ritten lijkt mij belangrijk. Dit hangt volledig samen met de uurtabellen. Zo maakt De Lijn telkens het onderscheid tussen weekdagen, zaterdagen en zondagen voor de normale lijnen. Bij schoolbussen en andere speciale lijnen, kan het nog iets ingewikkelder. Het lijkt mij zinvol om de wiki grondig (en duidelijk) om te vormen. Op 10 oktober 2010 21:10 schreef Jo winfi...@gmail.com het volgende: Ivo, ik zou op de wikipagina beschrijven dat er een heen- en een terugroute gemapt wordt. Dat is de enige wijze waar een routeplanner iets aan heeft. Als mensen het dan toch met 1 route/buslijn blijven mappen, dan betekent dat weer werk voor iemand die wel weet waar hij mee bezig is, om ze te ontdubbelen. De reden waarom 'k De Lijn had aangeschreven, was eigenlijk voornamelijk omdat 'k hun datamodel had willen zien. Ik vermoed namelijk dat we er zelfs met 2 relaties/lijn niet gaan komen. Wat met verkorte ritten? Wat met ritten die soms een andere route volgen, afh. vd dag van de week. Ik denk bijv. aan lijn 630. Die het industrieterrein niet bedient tijdens het weekeinde en die dan een stukje expressweg volgt. Of dat voor die lijn belang heeft, is natuurlijk de vraag. Als je de 'schedule' erbij neemt, is het wel duidelijk welke haltes wel of niet bediend worden. Maar dat is nu net het stukje dat we niet kwijt kunnen in de OSM-database. Het experiment met de child relations zou 'k maar niet vermelden, de kans dat dat bruikbaar is voor een routeplanner, is klein. Het zou een aanzienlijke tijdsbesparing kunnen betekenen, omdat het redundante informatie minimaliseert, maar het maakt het ook complexer. De pluging in JOSM kan er alleszins niet mee overweg. Ben, moeten we stemmen over 1 of 2 relaties/busroute? Of kunnen we ervan uitgaan dat iedereen inziet dat dat de correcte manier van werken is? Wie dat niet ziet, zou Oxomoa er 's op moeten nalezen. Die mensen hebben daar hard over nagedacht voordat ze dat document maakten. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] [Spam] list of user IDs having accepted the contributorterms
Very useful. I note that currently only 256 of the first 10,000 users are signed up only 1.5% for the first 100,000. It would be great to see what work the other people did and of we have the important ones. I realise that we are still in the voluntary phase but the numbers do seem pretty low. Fyi I am one of the first 10,000 who has not signed up while I wait for a resolution of the OS OpenData query. Has the process of deciding if enough people have signed up been agreed yet. At the SOTM I suggested that we should use the same 'referendum' of active contributors process to approve the change to ODbL as would then be used later for any subsequently changing the license. Regards, Peter On 9 October 2010 19:22, Matt Amos zerebub...@gmail.com wrote: as part of the voluntary relicensing phase of the move to ODbL, existing contributors have had the ability to voluntarily accept the contributor terms. to help the community assess the impact of the relicensing it was planned to make the information about which accounts have agreed available. this will help with the evaluation of the process and analysis of any consequent data loss, should the switch be made. at the last LWG meeting, having been put to the board for approval, it was decided to make this available [1], and i'm pleased to announce that this list is now up [2] and being regularly refreshed from the database every hour. i look forward to seeing the new analyses, visualisations and tools that can be built using this data. cheers, matt [1] https://docs.google.com/View?id=dd9g3qjp_86hf7fnqg8 [2] http://planet.openstreetmap.org/users_agreed/users_agreed.txt ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Flight paths in OSM
On Mon, Oct 11, 2010 at 12:37 AM, Nathan Edgars II nerou...@gmail.com wrote: On the other hand, it might be feasible to map approaches to airports as shown on official diagrams. There are also avigation easements that might be relevant here. Approaches (informally referred to as flight paths): definitely worth mapping. I say that because they appear in my local street directory, presumably as somewhere you wouldn't want to live. I definitely wouldn't map other flight paths/routes. The scope of OSM is already massive and difficult to cope with, without this unstoppable scope creep. On the other hand, an OpenAirMap project would be interesting. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal: winter roads
I think that whether a road is passable or impassable is certainly factual information, and no more subjective than whether it is 'residential', 'secondary' or 'track'. If a road is impassable in summer - or more than that, simply does not exist in summer, being just swamp - then this is a fact which should be tagged. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] How does one get the default cyclemap rendering amended?
If I look at the default map displayed on the web site then select base layer cycle map I get nice blue lines on roads with cycle lanes, and cycle paths which is perfect. However in Ontario we have paved shoulders which are tagged shoulder:access:bicycle=yes, together with shoulder:surface=paved as per the wiki. It would be nice if these could be rendered on the default cycle map in some way perhaps a dotted blue line? I'm not certain if roads that are signed bicycle=designated are rendered in a special way or not. I have a couple locally but sometimes it takes a bit of time before the rendered tiles reflect the map. Thoughts please. Many thanks Cheerio John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How does one get the default cyclemap rendering amended?
Hi, You can put in requests or bug reports through trac. Details are on the wiki: http://wiki.openstreetmap.org/wiki/OpenCycleMap I don't believe anything is done, or planned to be done, with bicycle=designated at the moment. Dave On Mon, Oct 11, 2010 at 1:58 PM, john whelan jwhelan0...@gmail.com wrote: If I look at the default map displayed on the web site then select base layer cycle map I get nice blue lines on roads with cycle lanes, and cycle paths which is perfect. However in Ontario we have paved shoulders which are tagged shoulder:access:bicycle=yes, together with shoulder:surface=paved as per the wiki. It would be nice if these could be rendered on the default cycle map in some way perhaps a dotted blue line? I'm not certain if roads that are signed bicycle=designated are rendered in a special way or not. I have a couple locally but sometimes it takes a bit of time before the rendered tiles reflect the map. Thoughts please. Many thanks Cheerio John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How does one get the default cyclemap rendering amended?
John wrote: However in Ontario we have paved shoulders which are tagged shoulder:access:bicycle=yes, together with shoulder:surface=paved as per the wiki. From a quick wiki search the shoulder proposal [1] looks to be still in draft, so hasn't even reached the RFC stage. It's not really surprising it isn't rendered. Ed [1] http://wiki.openstreetmap.org/wiki/Shoulder ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal: winter roads
I was just about to say that at least this winter road [1] is impassable at summer, but then I remembered about the Rinspeed sQuba [2]. [1] http://www.fotosidan.se/gallery/viewpic.htm/379398.htm [2] http://jalopnik.com/356461/rinspeed-squba-bonds-lotus-submarine-made-real Konrad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=incline
M∡rtin Koppenhoefer dieterdre...@gmail.com wrote in message news:aanlktimuklnfhudhvfk1=_nkcnoy9hwh-xk9rrqc_...@mail.gmail.com... 2010/10/8 Gorm E. Johnsen osml...@gorm.cc: Any objections to removing highway=incline and highway=incline_steep from Map Features and adding them to depreciated? not at all. remove them, please. I'd rather they were added to 'deprecated' though. -- Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[talk-au] Suburb - Bal
Hi, Can we do something about these Suburb - Bal boundaries boundaries? Eg: http://www.openstreetmap.org/browse/relation/101479 I understand that it came from the ABS import. But Melway shows this suburb as just Craigieburn: http://www.street-directory.com.au/sd_new/mapsearch.cgi?star=5heading=x=144.90646698866524y=-37.57921377002849level=5StateID=1 Anyone know where Melway gets that info from, and if we can get it too? Or do we just manually merge all these boundaries into the suburb of the same name? Ultimately, we want suburb names, not statistical divisions, surely... Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] An die thread-Piraten
Am 09.10.10 12:15, schrieb Tom Müller: Mmmh. Wenn ich http://news.gmane.org/gmane.comp.gis.openstreetmap.region.de als Newsgroup hinzufügen will kann ich nicht auf weiter klicken. Brauche ich da noch nen Addon oder so? Nö, so geht das ja auch nicht. Du legst in Thunderbird über Extras Konten-Einstellungen und Konten-Aktionen ein neues anderes Konto an, und gibst news.gmane.org als Server ein. Dann hast du links unterhalb der Lokalen Ordner einen neuen Ordner für gmane. Den wählst du an, und gehst rechts auf Newsgruppen abbonieren, und wählst dort in dem Baum die Gruppe gmane.comp.gis.openstreetmap.region.de aus; und klickst auf abbonieren. Wenn du erstmalig über gmane schreiben willst, bekommst du eine email-Aufforderung, die du beantworten musst, bevor der Beitrag in die Liste eingestellt wird. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 00:07:38 schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem Semikolon so eine Sache ist ;-) das liegt aber meist nicht am Semikolon selbst, sondern an den Anwendungen, die das nicht verstehen (wollen)... +1 Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr hoch, das keiner der Renderer so ein Haupttag findet. Ich erwarte nicht, das sich das in Zukunft großartig ändern wird. Hier taggt jemand aber nur noch für bloed nur, dass sich sowas nicht anders darstellen laesst. [...] Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). +1 +1 Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Das ist auch ganz unabhaengig davon, um welches Tag oder welche Kombinationen es sich handelt. Es stellt sich nur die Frage, tut man's oder tut man's nicht. +1 Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) -/- amenity=cafe;restaurant cuisine=greek;italian Als diese Unsitte mir area=yes eingeführt wurde, verpassten wir die Gelegenheit, die Bodennutzung mit area zu definieren. area=residential, building=wohnhaus... . Der Zug ist abgefahren. Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 08:34:10 schrieb Ulf Lamping: Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Das aber ist und muss dem Renderer freigestellt sein. Eben das ist ja der Vorteil bei OSM, dass erfasst wird, was vorliegt. Wer das wie auswertet, ist für die Erfassung _absolut_ egal. Ich habe selbst schon einiges erfasst, was nirgends gerendert wird, so what! Wenn ich es brauche sollte, schreibe ich halt irgend etwas, oder lasse es schreiben. Wir können doch nicht bei der Erfassung Rücksicht auf vermeintlich unzureichende Auswertesoftware nehmen! Wenn wir immer nur das erfasst hätten, was im Moment gerendert wird, würde die Karte bis heute nur aus einem Strickmuster von unklassifizierten Straßen und Wegen bestehen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Sonntag 10 Oktober 2010 21:48:30 schrieb Jan Tappenbeck: ... nämlich das semikolon ist dem tag sein tod ! -1 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 08:59, schrieb Wolfgang: amenity=cafe;restaurant cuisine=greek;italian Ich denke mal, dass man als Programmierer einfach nicht entscheiden kann (oder will), was in so einem Fall gerendert (ausgewertet) werden soll: Soll das Symbol für Cafe oder für Restaurant dargestellt werden? Gibt es dort griechischen Kaffee und italienisches Essen oder italienischen Kaffee und griechisches Essen oder griechisch-italienisches Essen und auch Kaffee? Wenn ich soetwas auswerten wollte, würde ich bestenfalls das jeweils erste Element nehmen, also hier ein griechisches Cafe darstellen. Stell Dir mal vor, man will eine Liste mit griechischen Restaurants machen. Soll das dann aufgenommen werden oder nicht? Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Etwas Anderes ist es bei den opening_hours, dort ist klar definiert, wie das Semikolon zu interpretieren ist. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Bei sowas wie amenity=bank;atm ist die Sache klar, da setze ich zwei Nodes. Bei sowas wie amenity=cafe;restaurant ist es etwas bloeder, da entscheide ich mich in der Regel fuer eins. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Das Beispiel cafe/restaurant ist zugegeben in vielen Fällen eine Werbeaussage. Trotzdem gibt es den Unterschied: Viele Restaurants haben Mittags und Abends auf, viele Cafés haben vom Vormittag bis späten Nachmittag geöffnet. In Restaurants liegt das Schwergewicht auf festen Mahlzeiten, während Cafés nahezu ausschließlich Kaffee, Kuchen und ggf. Eis anbieten. Wer beides hat, ist halt Café;Restaurant. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Gar nicht. Bitte beim Löschen von Objekten jeden Einzelfall prüfen (scnr). Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Das ist jetzt nicht dein Ernst? Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Die Öffnungszeiten werden auch nicht gerendert, aber trotzdem eingetragen. Es gibt auch andere Software als Renderer. Gerade Anwendungen wie der openstreetbrowser sind prinzipiell in der Lage, gezielt Mehrfacheigenschaften auszuwerten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag, 11. Oktober 2010 08:59:18 schrieb Wolfgang: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Da möchte ich jetzt doch mal widersprechen. Ich tagge sehr wohl für Renderer, Router und Auswertesoftware, und eher nicht für die Datenbank. Nicht für den Renderer taggen bedeutet für mich, dass ich keine verfälschten Daten eintrage, um damit ein bestimmtes Render-Ergebnis zu erreichen. Es ist auch klar, dass ich keine Daten entferne, bloß weil sie nicht gerendert werden. Und ich gestehe auch gerne zu, dass zum Zwecke einer besseren Datenerfassung hin und wieder Änderungen eingeführt werden, an die bestehende Auswertesoftware erst angepasst werden muss. Aber dass man die Möglichkeiten der bestehenden Auswertesoftware und gegebenenfalls nötigen Änderungsaufwand völlig ignoriert, kann ich nicht verstehen. Wie gesagt, _ich_ mappe nicht für die Datenbank. Gruß, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Ulf Lamping wrote: Am 11.10.2010 09:09, schrieb Wolfgang: Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Nein, wie Stephan an anderer Stelle am Beispiel gezeigt hat, geht der Aufwand schon damit los, daß man sich überhaupt erstmal überlegen muß, was denn der Mapper mit dieser Kombination gemeint haben könnte. Die Darstellung ist dann einer der weiteren nicht trivialen Schritte. Und das muß man dann für jedes Tag einzeln bewerten. +1 -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5622338.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] Darstellung von geotagged Bildern in OSM
Hallo zusammen, vielen Dank für Eure Tipps. Ich werde mich in den nächsten Tagen mit diesen auseinander setzen. Ausschliessen kann ich allerdings sofort die Lösungen, bei denen man Bilder auf irgendeinen externen Server hochladen muss. hike 39 Am 08.10.2010 11:35, schrieb hike39: Hallo, ich bin auf der Suche nach einer Möglichkeit Photos, die ich über das JOSM-Addon Photo Geotagging mit Positionsinfos versehen habe, auch in OSM anzeigen zu lassen. Gibt es hierzu schon eine Lösung? Ich habe gerade überall im Wiki und in den dt. Diskussionsgruppen gesucht, aber leider nichts gefunden. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:30:57 schrieb Frederik Ramm: Hallo, Wolfgang wrote: Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Vielleicht verschwindet das Semikolon und wird durch etwas anderes ersetzt. Ich glaube aber nicht, dass Mehrfacheigenschaften verschwinden werden. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Ist auch OK. Dann rendert es halt ein anderer. Später. :) Ich kann es aber jetzt auswerten. Z.B. Summe der italienischen Restaurants in x-Stadt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 10:15, schrieb Wolfgang: Hallo, Am Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Hier argumentiert Frederik mit konkreten Problemen auf die ein Entwickler stößt, wenn er es denn einbauen wollte. Du argumentierst hingegen mit: es hätte, muß es, ... Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Es geht hier nicht darum, ob man sowas eintragen kann (oder sollte), sondern wie es sinnvoll gemacht wird. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Platzierung stop_position-Knoten im Oxomoa-Schema
Am 8. Oktober 2010 18:45 schrieb Benjamin John o...@bejotel.de: Am 08.10.2010 16:37, schrieb Claudius: Szenario ist eine Buslinie mit Haltestelle an einer Kreuzung, wobei der Bus in jeder Richtung jeweils *vor* der Kreuzung hält. die stop_position jeweils dort projeziert auf die Straße (=Teil des highway, Mitte der Straße), wo der Bus hält (m.E. Vorderkante Bus bzw. projezierte Position des Haltestellenmastes). In diesem Fall also mind. 2 davon. Ein Mapper meinte, dass der eine dafür nötige stop_position-Knoten dann auf den Kreuzungsknoten gehöre (und verwies dabei unter anderem auf die Verwendung in Aachen, die ich mir aber noch nicht angeschaut habe). das können sich die Aachener ja nochmal überlegen, m.E. ist es jedenfalls so falsch. Meinem Verständnis nach mappt man zwei stop_positions jeweils auf dem Weg vor (==lotgefällt) auf dem Weg der Buslinie. Ich bin auf jeden Fall dafür für jeden Stop einen Knoten zu erfassen. Also in diesm Fall zwei, und wenn sich an der Kreuzung zwei Linien kreuzen dann auch vier oder wie viel auch immer nötig sind. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TüV Reinland Breitbandatlas basiert auf OSM-Daten
Am 8. Oktober 2010 10:21 schrieb Oliver Tonnhofer o...@omniscale.de: Wir stellen die Daten bereit und haben mit der Kartenanwendung selber nichts zu tun. Wir haben das allerdings weitergeleitet und denken, dass da heute noch nachgebessert wird. ja, danke, jetzt steht da klar Hintergrundkarte Openstreetmap, CC-BY-SA 2.0, wie es auch im OSM-Wiki vorgeschlagen wird. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:54:28 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. 0/-1 In deinem speziellen Beispiel ginge das, aber für das Beispiel Amenity oder Cuisine geht es nicht, weil damit die Statistik in die Tonne getreten würde. Wer das für seine Auswertung so machen will, dem steht das frei. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. Hier habe ich ein grundlegendes Verständnisproblem - ich finde das Problem einfach nicht. Wenn ich das Datenschema nicht anpasse, bekomme ich für den key amenity den Value cafe;restaurant. Jetzt mit einer klitzekleinen Programmzeile eben prüfen, ob ein Semikolon vorliegt, und im Falle, dass dieses zutrifft, einen Value-Array mit den einzelnen durch Semikolon(s) getrennten Werten erzeugen. Hier den ersten Wert dem Value wieder zuweisen und den übrigen Programmablauf so lassen, wie bisher. Damit wird ausschließlich der erste Wert benutzt. Nicht optimal, aber für den 08-15-Renderer eine brauchbare Möglichkeit. Geht viel schneller als die ganzen Diskussionen über das Semikolon in nicht nur diesem Thread. Die Idee mit der Sortierung ist auch nicht schlecht. Wenn ich den erzeugten Value-Array noch sortieren lasse, kann ich auf bestimmte Kombinationen abprüfen. Das geht allerdings auch ohne Sortierung. Wer den Programmablauf beschleunigen will, könnte für die Keys und Values in der DB eine zusätzliche Spalte für Integers einführen. Dann bekäme jeder Key und Value eindeutige int, die nur einmal erzeugt werden muss (und einmal für den Inhalt jedes Updates). Die Queries könnten dann integers zurückgeben, die viel schneller (automatisch) auszuwerten sind. Nur so als Idee. Zugegeben einmalig viel Aufwand. Beschleunigt aber erheblich mehr, als die Auswertung von ein paar Semikolons sonst kosten könnte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo zusammen, Auf dem Toolserver werkelt inzwischen Tirex, daher sollten veraltete Kacheln der Vergangenheit angehören. Grund genug, meine Fahrrad-Karte zu überarbeiten: http://access.t-i.ch/extended-bicycle.html Neu ist insbesondere die dünne Mittellinie, welche die Oberfläche visualisiert: Schwarz für gescholssene/geteerte Oberflächen Weiss für verfestigte/bearbeitete Oberflächen Rot für naturbelassene Oberflächen schönes Beispiel: http://access.t-i.ch/extended-bicycle.html?zoom=17lat=47.39758lon=8.54614layers=B000T Wünsche, Anregungen und Fehlermeldungen bitte hier oder auf der Wiki- Seite: http://wiki.openstreetmap.org/wiki/User:T-i/Access-Map Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 11:31, Friedhelm Schmidt wrote: Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5622707.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] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:59:30 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Du übersiehst, dass der Programmierer hier ein im Grunde größeres Problem hat. Die Eigenschaften sind nach wie vor mehrfach vorhanden. An dieser grauenvollen Wirklichkeit führt auch dieses Schema nicht vorbei. Aber die Auswertung muss erkennen, dass cuisine_greek und italian sich auf die gleiche Eigenschaftsgruppe beziehen. Zusätzlich zum Vorhandensein der Mehrfacheigenschaft muss diese Mehrfacheigenschaft erkannt werden, sonst malt der Renderer das eine Icon über das andere. Oder er nimmt immer das zuerst gefundene. Damit wären wir auch nicht weiter. Eine Software, die ein Icon für eine relativ häufige Kombi wie diese hier darstellen könnte, hätte einen erheblichen Mehraufwand, weil sie die Kombi erst suchen müsste. Aber die Eigenschaftenliste wird in jedem Editor länger und auch hier muss die humane Schnittstelle die Mehrfacheigenschaft erst mühsam erkennen, während das Semikolon diese brutal vor das entsetzte Auge zerrt. Man muss sich immer überlegen, dass es sich letztlich um ein grundsätzliches Problem handelt. Wenn nur ein yes-Tag dabei ist, fällt das Problem nicht auf. Wenn aber alles so getaggt würde, weil es scheinbar einfacher ist, würde die Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. Aber ein Problem zeigt sich immer am Extremfall, und so eine Liste möchte ich weder im josm noch im merkaartor editieren müssen. Mehrfacheigenschaften sind trotzdem drin. Wenn man das Schema noch etwas ausbaut, kann das yes/no weggelassen werden, und wir sind beim valuelosen tagging. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). Da würde ich auf die DB-Struktur zu dem Zeitpunkt tippen. Ist aber nur Spekulation. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Farmland
Am 10. Oktober 2010 23:23 schrieb minze my-email-confirmat...@online.de: natural wären dann Naturschutzgebiete, wo die Nutzung verboten ist, oder wie grenzst Du das ab? Wie bei natural=wood vsv Landuse=forest, steht in der wiki. funktioniert da ja auch schon nicht. Bei Heiden ist es noch schwieriger als bei Wäldern, versuchen könnte mans trotzdem mal, die meisten Mapper haben halt kaum ein Auge / Vorbildung / Acht auf solche feinen Details. NSGs sind handlungsleitende Widmungen und haben mit der vorgefundenen Struktur weniger zu tun. Nicht jeder Naturwald ist ein Schutzgebiet - insbesondere international gesehen. da bin ich allerdings voll bei Dir. ... Den Wert von crop könnte man auch lateinisch eintragen, so dass es eindeutiger wird (vgl. natural=tree). ja. wie? So: # name=tomatoes # genus=Solanum # species:en=tomato ? nein, so nicht. Ich nehme an, das hast Du absichtlich so geschrieben? Warum sollte der Name im Plural sein? Name von was? Willst Du einzelne Tomaten taggen? Genus braucht man prinzipiell nicht, weil er in der Spezies schon enthalten ist und für sich betrachtet noch wenig aussagekräftig, zumindest bei Tomaten. species=solanum lycopersicum hatte ich gedacht, bin aber kein Biologe und evtl. gibt es da auch unterschiedliche Spezies (k.Ahnung, ob Fleischtomaten, Kirschtomaten, Flaschentomaten, San Marzano, etc. alle dieselbe Species sind). Prinzipiell läuft das halt auf eine komplette Neuregelung hinaus, da für Wiesen bisher landuse=meadow dokumentiert und im Einsatz ist. Im Prinzip ist das aber eine Untergruppe von farmland, da stimme ich auch zu. eigentlich haben wir nur landuse und farmland getauscht, damit - landuse=grass nicht weiter belastet wird - Unterschied Wiese und Weide möglich wird ist er schon jetzt: meadow und pasture - eine Oberkategorie farmland entsteht. das meinte ich mit alles umkrempeln Ein kleiner Fehler in meinem vorherigen Tagg-Vorschlag ist allerdings, dass Schlüsselnamen farmland zweimal, also redundant vorkommen. Das finde ich nicht schön. einmal als key, einmal als value, das finde ich nicht so schlecht, da es einer einfach nachvollziehbaren Systematik folgt und eine Hierarchie bildet. zum Begriff Wiese: es ist nicht auszuschließen, dass Wiesen vor nicht zu langer Zeit beweidet wurden. das ist allerdings egal. Wenn Du geschichtliche Informationen taggen willst, dann mit einem klaren Schema. Siehe auch die Meisten der in der wiki und in google zu findenen Wiesenbilder: sie wären heute ohne viel Aufwand zu beweiden. klar, das liegt in der Natur der Sache. Eine Unterscheidung in Weide und Wiese würde landuse m.E. unnötig verkomplizieren. manche wollen das offenbar trotzdem tun. Hattest Du nicht oben selbst geschrieben, diese Unterscheidung würde mit Deinem Vorschlag möglich ? Ich würde einen neuen Hauptkey landcover einführen, um erstmal Klarheit zu haben, was in landuse gehört, und was nicht. sieht schick aus, aber ich wäre vorsichtig. Einen neuen Hauptschlüssel sehe ich noch nicht. Das wäre auf jeden Fall komplizierter, ein Tagg mehr. es wäre ein Start um nach und nach zu migrieren. surface=grass würde bei uns auch gut passen, da Gras auf dem Banquette oder Mittelstreifen tatsächlich nur eine Oberfläche ist und u.A. nichts mit Wiesen- oder Grünlandboden zu tun hat. +1 Gruß Martin PS: Es würde die Diskussion sicher erleichtern, wenn man mal eine Zusammenfassung im Wiki hätte, am besten als Proposal (Status Draft) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 12:45:36 schrieb Walter Nordmann: Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: - was ist mit den nicht erreichten....
Am 10. Oktober 2010 13:47 schrieb Frederik Ramm frede...@remote.org: Jan Tappenbeck wrote: immer noch positiv gegenüberstehen und nur weil diese nicht mehr erreichbar sind, vielleicht inzwischen ein anderes Hobby haben, sollen deren Daten gelöscht werden ?!?!? ja Ob man allerdings den von Dir vorgeschlagenen weiteren Schritt gehen wird, dass man Daten der nicht-erreichten bis auf Widerspruch erstmal behaelt, das weiss ich nicht; ich koennte mir vorstellen, dass das eine Einzelfallentscheidung sein koennte. Wie sollte man den Einzelfall entscheiden? Auf welcher Grundlage? Das einzige was ich mit rechtlich vorstellen kann, ist zu sagen, cc-by-sa schützt die Daten sowieso nicht (was aber auch nicht ganz klar ist). OK, eine andere Möglichkeit wäre evtl. ein Verblassen des Schutzes: wenn man eine grob dahingerotzte Straße (oder anderes Feature) nach und nach so dermaßen überarbeitet hat, dass vom ursprünglichen Edit nichts mehr übrig ist. Andererseits hat das Urheberrecht in manchen Laendern tatsaechlich eine Regel, die sinngemaess besagt, dass wenn man mehrmals sorgfaeltig versucht hat, den Rechteinhaber zu erreichen, und das fehlschlug, man bis zu anderslautender Nachricht von einer Zustimmung ausgehen darf. das kann allerdings erst dann mögliche Handlungen vorgeben, wenn wir entweder mehrere OSMs für verschiedene Länder machen (m.E. komplett unvorstellbar) oder diese Rechtsauffassung in allen Ländern gilt (auch das unwahrscheinlich). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Am 10. Oktober 2010 16:30 schrieb Matthias Versen ma...@mversen.de: Jan Tappenbeck wrote: gibt es eine Möglichkeit irgendwie festzustellen wer das Element XYZ einmal erstellt hat ?? Bedingt denn beim splitten eines ways entsteht ein neuer und ein alter Teil. Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 13:01, Wolfgang wrote: Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Ich denke, das hat niemand vor. Die Vorteile liegen aber absolut auf der Hand. Ohne das geprüft zu haben: - Ein Bottleneck an der API ist der Datentransfer - komprimierung spart hier. - Bottleneck in vielen Anwendungen ist die Festplatte - Komprimierung hilft. Komprimierte Daten sind selten gut, wenn es um kleine Ausschnitte geht: Zwei Häuserblocks runterladen, um in JOSM einen Briefkasten einzutragen ist unspannend im komprimierten Format. Aber es gibt ja andere Anwendungen, und insofern finde ich auch da ein offenes, wenn auch nicht unbedingt gut menschenlesbares Format eine gute Sache. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gültige XSD für API 0.6
Hallo zusammen! Ich bastel gerade an einem Tool, das OSM-Daten aufbereiten soll und suche daher nach einer gültigen XSD für die API 0.6. Im Wiki habe ich zwar eine XSD gefunden[1], diese lässt sich aber nicht gegen aktuelle Serverfiles validieren (unter anderem fehlt das bounds Tag. Daher meine Frage an die Liste: Gibt es eine aktuelle XSD für die API 0.6? Das würde mir die Arbeit sehr erleichtern :) Gruß, Philip [1]: http://wiki.openstreetmap.org/wiki/API_v0.6/XSD Exklusiv: Neue E-Mail-Adresse @iPhone.de jetzt verfügbar! Sichern Sie sich jetzt ihre persönliche http://www.iphone.de/iphonemail/index.html?pid=10111947021 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 12:33, schrieb Peter Wendorff: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Natürlich gelten die Eigenschaften hier oft nicht für beide Teile, das fängt schon beim Namen an - der Geldautomat hat in der Regel gar keinen. Aber amenity=bank;atm ist sowieso ein schlechtes Beispiel. Denn das ist kein Objekt, das gleichzeitig ein Geldautomat und eine Bank ist. Das ist ein Geldautomat *in* einer Bank. Also sollte man m.E. einen node mit amenity=atm in der Fläche der Bank platzieren. Dann kann man auch noch zusätzliche Tags für den Geldautomaten und die Bank unabhängig vergeben. An sich könnte eine Software so eine liegt im Polygon-Geschichte sogar auswerten und auf die is in-Beziehung kommen. Praktischerweise funktionieren die üblichen Anwendungen aber auch ohne diesen Zusatzaufwand ganz gut. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Am 11.10.2010 13:37, schrieb Philip Gillißen: Daher meine Frage an die Liste: Gibt es eine aktuelle XSD für die API 0.6? Es gibt nicht das API 0.6 Schema sondern nur eine Erklärung, was die einzelnen Tags in den XML-Files genau bedeuten. Daher benutzt jedes Tool (Planet-Dumper, API, Osmosis, JOSM) seinen eigenen Dialekt. Es sollte jedoch Möglich sein, ein Schema zu definieren, das alle Dialekte abdeckt -- nur ob das ist was man(tm) will... Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 12:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. +1 Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Hallo, Peter Körner wrote: Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Oder wir kommen komplett von diesem ueberkandidelten XML weg, dann braucht man auch keine Schemata mehr ;) 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] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 12:48 schrieb Wolfgang wolfg...@ivkasogis.de: Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. +1 und die Hierarchien, die wir durch Doppelpunkte zur Strukturierung erzeugen, mal eben ignoriert. Diese Liste würde auch durch Mehrfachwerte kaum übersichtlicher: im Gegenteil (zugegebermaßen sowohl von den konkreten Editoren als auch von den persönlichen Präferenzen und auch von der Maus/Steuerung abhängig): Während lange (Mehrfach-)Werte in der meist schmalen (in Potlatch 1 definitiv zu schmalen) Valuespalte oft horizontales Scrollen erfordern, ist eine lange Liste in der Regel durch bessere Unterstützung von vertikalem Scrolling (Mausrad) einfacher handlebar. Wenn wir uns einem Punkt annähern, dass viele Objekte so lange Attributslisten haben, wird sich sicherlich auch auf Editorseite eine Lösung finden, diese gruppiert / strukturiert zu präsentieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Am 11.10.2010 15:50, schrieb Frederik Ramm: Hallo, Peter Körner wrote: Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Oder wir kommen komplett von diesem ueberkandidelten XML weg, dann braucht man auch keine Schemata mehr ;) Egal welches Format wir zum Serialisieren der Daten in einen Byte-Strom benutzen (XML, JSON oder PBF) - es sind immer Schemata nötig, die möglichst einheitlich sein sollten. Ich fürchte mich ja ein wenig vor den PBFs da es eben noch nicht für jede Sprache eine Bindung gibt (PHP? Python?), ich jedoch gerne PHP als Glue-Sprache für alle möglichen Auswertungen (z.B. [1]) verwende. Es gibt derzeit nach meinem Wissensstand nicht einmal eine allgemeine C oder C++ Lib, die man mit PHP verbinden könnte, obwohl sowas aus pbf2osm [2] hervor gehen könnte. XML Support ist dagegen Allgegenwärtig. Lg, Peter [1] http://svn.toolserver.org/svnroot/mazder/experimental_osmdoc_import/ [2] http://git.openstreetmap.nl/index.cgi/pbf2osm.git/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 00:07, schrieb Guenther Meyer: bloed nur, dass sich sowas nicht anders darstellen laesst. http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
On 10/11/2010 04:44 PM, Peter Körner wrote: Ich fürchte mich ja ein wenig vor den PBFs da es eben noch nicht für jede Sprache eine Bindung gibt (PHP? Python?), ich jedoch gerne PHP als Glue-Sprache für alle möglichen Auswertungen (z.B. [1]) verwende. für PHP siehts tatsächlich noch finster aus, aber ich werde mich vermutlich in kürze darauf stürzen ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 17:10, schrieb Peter Körner: http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Oh, eine API V0.7 Wunschliste. Gut gefällt mir: No trolls We need to ruthlessly hunt down and exterminate trolls wherever they may be found. :-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 12:33 schrieb Peter Wendorffwendo...@uni-paderborn.de: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. Das Beispiel von Bank und Geldautomat ist eins, Bei Tankstellen ist die Zahlungsmodalität während der Öffnungszeiten und am Automaten zu unterscheiden. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. Beispiel Tankstelle: Gleiche Zapfsäule(n), aber unterschiedliche Daten; mehrere Nodes machen? blöde Redundanz von Sprit-Sorten, operator, brand etc. Beispiel Post: operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) Ich merke immer wieder, dass Leute Nodes mergen, die unterschiedliche; auch widersprüchliche Attribute haben. Das wird hier erst recht der Fall sein. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte (Ausnahme z.B. Raffaello in Kassel - wobei das italienische Küche ohne Pizza mit ägyptischem Koch ist; lecker (und leider teuer) isses trotzdem). Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. Vielleicht ist dies wieder ein Beispiel für eine blöde Vermischung von Tags. Als ich wegen dem Raffaello grade meine Freundin fragte, meinte sie andererseits: Pizza ist für mich italienisch. wenn da Pizza und Türkisch steht, würde ich Lahmacun erwarten. Das ist sicherlich geprägt von der Anwenderseite - die Tags sind IMHO nicht so gemeint und zu interpretieren. Als Beispiel zeigt es aber, denke ich, dass mehrfache Werte durchaus sinnvoll sein könnten, ohne dass das ein Fehler in den Daten wäre (wenn man es nicht grundsätzlich verbietet). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO geht nicht auf 60Csx
Hallo *, die neue Bayernkarte vom 2010.10.09 funktioniert wieder wie erhofft. Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offline Tile Server?
André Joost schrieb am 10.10.2010 18:14:
Eigentlich brauchst du gar keinen Server dafür. Es reicht, wenn du den
Aufruf in Openlayers in der openStreetMap.js umbiegst:
OpenLayers.Layer.OSM.Mapnik = OpenLayers.Class(OpenLayers.Layer.OSM, {
/**
* Constructor: OpenLayers.Layer.OSM.Mapnik
*
* Parameters:
* name - {String}
* options - {Object} Hashtable of extra options to tag onto the
layer
*/
initialize: function(name, options) {
var url = [
file:///D:/Tiles/Mapnik/${z}/${x}/${y}.png
];
options = OpenLayers.Util.extend({ numZoomLevels: 19 }, options);
var newArguments = [name, url, options];
OpenLayers.Layer.OSM.prototype.initialize.apply(this,
newArguments);
},
CLASS_NAME: OpenLayers.Layer.OSM.Mapnik
Danke fuer den Tipp. Das sieht doch so aus, als ob es mein Problem loesen
muesste, und neben bei lerne ich dann auch gleich noch mal OpenLayers kennen :-)
Gruss
Torsten
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 17:58 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. ja, aber es bleibt falsch. Es gibt sehr viele Fehler in den Daten, manche sind offenkundig, andere eher versteckt oder im Detail. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte ja klar Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Am 11.10.2010 15:33, schrieb Peter Körner: Es gibt nicht das API 0.6 Schema sondern nur eine Erklärung, was die einzelnen Tags in den XML-Files genau bedeuten. Daher benutzt jedes Tool (Planet-Dumper, API, Osmosis, JOSM) seinen eigenen Dialekt. Aber warum ist das so? Das OSM-Format ist doch nicht so kompliziert, um eine Basis-Abdeckung zu bekommen. Es sollte jedoch Möglich sein, ein Schema zu definieren, das alle Dialekte abdeckt -- nur ob das ist was man(tm) will... Die Dialekte braucht es ja nicht abdecken, nur das generelle OSM-XML-Format, das der Server liefert. Wer ist denn zuständig für die Server-Komponente, die die .osm-Dateien erstellt? Gruß, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyzSFgACgkQYNYFUFLXAD1IQgCfTZY8sKZ6lkcEgC7a+o3UnJxr LWYAmQFiHM3Z90fuHquxlnEyXp52aCrA =kG63 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 17:58 schrieb Peter Wendorffwendo...@uni-paderborn.de: Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. brand ist die Marke... Ich hab zwar kein praktisches Beispiel, wo diese Kombination tatsächlich vorkommt, aber auch ein Laden an sich kann ein brand haben. Bei Kleidungsgeschäften ist das häufig, bei Schreibwarenläden und Kiosken, die meist als Post-Annahmestellen handeln, kenne ich es tatsächlich nicht. Trotzdem finde ich diese Lösung aus dem Grund nicht gut. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) Als Wiener Schnitzel sicherlich, aber ob das Schweineschnitzel Wiener Art wirklich auf Österreich zu beschränken wäre, weiß ich nicht - nichtmal, ob die Österreicher (oder zumindest die Wiener) damit wirklich glücklich sind Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 20:53 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? es gibt ja auch noch regional, was für Dein Bayern-beispiel wohl am besten passt. Das ist übrigens weltweit auch der häufigste Wert überhaupt im cuisine-tag http://taginfo.openstreetmap.de/keys/cuisine wobei die deutsche Küche international auch einen guten Stand zu haben scheint (gleich nach burgern, italienisch und chinesisch) ;-) Sowas wie cuisine=german macht eigentlich sowieso keinen Sinn, wie Du selbst auch schon erkannt hast, es gibt nicht die deutsche Küche, sondern jeweils regionale Varianten davon. Wäre was für einen Subtag. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
nochmal kurz zum Thema: cuisine=pizza;kebab 111x cuisine=kebab;pizza 158x eine Definition, dass die Reihenfolge durch den Mapper alphabetisch erfolgen sollte, würde hier schonmal für sowas wie cuisine=pizza;kebab 3x cuisine=kebab;pizza 266x sorgen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Hallo, Am Montag 11 Oktober 2010 schrieb M∡rtin Koppenhoefer: Am 10. Oktober 2010 16:30 schrieb Matthias Versen ma...@mversen.de: Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: - was ist mit den nicht erreichten....
Am 10.10.2010 13:20, schrieb Jan Tappenbeck: Aus eigenen Gesprächen habe ich erfahren das Mapper gesagt haben - ich mache kein Kreuz - sollen andere über irgendwelche Lizenzen entscheiden... Denkt bitte auch über dieses nochmal nach Das blöde ist, dass die bereits ein Kreuz gemacht haben, nämlich in dem Moment, in dem sie sich registriert haben. Dieses Kreuz verbietet den von dir vorgeschlagenen Weg denn es kann nicht einfach ignoriert werden. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Hallo, Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Hier sind jetzt ein paar Sachen durcheinander gekommen. 1. Wir haben keine History aus der Zeit vor API 0.5, also vor Oktober 2007. Damals hatte OSM rund 30 Millionen Nodes und 3 Millionen Ways, heute haben wir 750 Millionen Nodes und 60 Millionen Ways, d.h. zu etwa 5% unserer heutigen Daten fehlt die History (in der Praxis duerfte die Zahl kleiner sein, weil viele von diesen Altdaten vermutlich auch im Lauf der Zeit geloescht wurden). Im Zuge des Lizenzwechsels werden wir vermutlich ein altes Backup raussuchen muessen, um auf die alte History zuzugreifen. 2. Changesets wurden erst mit API 0.6, also seit April 2009, aufgezeichnet. Allerdings wurden beim Wechsel von 0.5 zu 0.6 Changesets fuer die damals bestehende History synthetisiert, indem Aenderungen des gleichen Users im gleichen Zeitraum zusammengefasst wurden, so dass man weitgehend so tun kan, als ob es schon immer welche gegeben haette. 3. In der Tat kann das Aufspalten eines Ways, oder auch das Loeschen und Neuanlegen eines Ways, aus einer Analyse der Changesets erkannt werden. 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] Element-Historie.....
Am 11.10.2010 23:12, schrieb Frederik Ramm: Hallo, Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Hier sind jetzt ein paar Sachen durcheinander gekommen. 1. Wir haben keine History aus der Zeit vor API 0.5, also vor Oktober 2007. Damals hatte OSM rund 30 Millionen Nodes und 3 Millionen Ways, heute haben wir 750 Millionen Nodes und 60 Millionen Ways, d.h. zu etwa 5% unserer heutigen Daten fehlt die History (in der Praxis duerfte die Zahl kleiner sein, weil viele von diesen Altdaten vermutlich auch im Lauf der Zeit geloescht wurden). Im Zuge des Lizenzwechsels werden wir vermutlich ein altes Backup raussuchen muessen, um auf die alte History zuzugreifen. 2. Changesets wurden erst mit API 0.6, also seit April 2009, aufgezeichnet. Allerdings wurden beim Wechsel von 0.5 zu 0.6 Changesets fuer die damals bestehende History synthetisiert, indem Aenderungen des gleichen Users im gleichen Zeitraum zusammengefasst wurden, so dass man weitgehend so tun kan, als ob es schon immer welche gegeben haette. 3. In der Tat kann das Aufspalten eines Ways, oder auch das Loeschen und Neuanlegen eines Ways, aus einer Analyse der Changesets erkannt werden. Bye Frederik also wenn ich das richtig sehe ist das eine menge aufwand die alten daten zu löschen und wenn es einer darauf anlegt ist eine verschleierung möglich ?!?! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Vie con binari tramviari e corsie trasporto pubblico
Il 10 ottobre 2010 16:22, Federico Cozzi f.co...@gmail.com ha scritto: 2010/10/10 Michael von Glasow mich...@vonglasow.com: Esempio [1]: metterei una way taggata highway=*;oneway=no (quest'ulteriore non è strettamente necessario), poi un'altra taggata railway=tram usando gli stessi punti. Non sono d'accordo, la way è una sola e i tag vanno applicati alla medesima way. +1 Ciao, Federico ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [Gfoss] Mapping party a Foligno
Che bello!!! Spero di esserci anch'io -- Lorenzo Di Tullio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
Il 10 ottobre 2010 11:21, Fabio Alessandro Locati fabioloc...@gmail.com ha scritto: 2010/10/10 Niccolo Rigacci o...@rigacci.org: On Sun, Oct 10, 2010 at 10:46:23AM +0200, iiizio iiizio wrote: Sarebbe interessante sapere la percentuale di mappa che sopravviverebbe al cambio licenza più che la lista degli id. Non mi è chiaro se sono stati chiariti i seguenti dubbi: 1) I contributi derivati da oggetti creati da chi vuole rimanere con la vecchia licenza, rimangono con la vecchia licenza oppure vince la licenza dell'ultimo utente che ha fatto edit? Non ci sarà, alla fine, una 'nuova licenza' e una 'vecchia licenza' ci saranno (sempre se la procedura viene portata a termine) elementi con la nuova licenza o elementi eliminati. Secondo le attuali policy (ancora in discussione) tutti gli edits su un oggetto dopo un edit di un utente che non ha accettato la nuova licenza, verrebbero persi. Qualcuno sa quando succederà questo? Il rischio è quello di vedersi sparire le strade principali (quelle che c'erano già anni fa) perché gli utenti che le hanno importate non sono più contattabili / sono contrari al cambio di licenza. Se le cose stanno davvero così, una way creata da X e modificata venti volte da me dopo sarebbe eliminata perché io ho accettato la nuova licenza e X no. Ad ogni modo, fatta la legge trovato l'inganno: basta scaricarsi i dati attuali, e quando i dati non licenziati saranno eliminati li si ricaricano. Tutto il processo è un po' ridicolo... 2) Nel caso in cui debba valere la licenza originale, è davvero possibile risalire tutta la catena di edit per sapere se un elemento è contaminato dalla licenza CC-By-SA? La history completa è presente ;) Ecco, questo non è chiaro. La way viene eliminata ma il suo storico rimane presente? -- Niccolo Rigacci Firenze - Italy Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [ANN] osmstats 1.0
Il 10 ottobre 2010 18:45, David Paleino da...@debian.org ha scritto: Pur avendo azzoppato la parte più dinamica e simpatica della webapp (/graphs/, ossia la generazione dinamica di grafici), per motivi di performance dell'attuale server (o di poca ottimizzazione del codice, da vedere), sono lieto di annunciare OSMStats 1.0 http://osmstats.hanskalabs.net/ L'idea è di fare l'analisi settimanale dell'italy.osm in maniera automatizzata. Bello! Spero solo, visto che hai voluto rilasciare la versione 1.0 il 10/10/10, che non dobbiamo aspettare l'11/11/11 per avere il primo minor update ;-) L'interfaccia è sicuramente migliorabile, quindi non esitate a segnalare bug/richieste a [0]. A parte essere un po' spoglia, non mi sembra ci sia molto da fare. Bella! Attualmente l'analisi viene effettuata solamente su alcuni tags [1]. Nel caso vogliate altri tag, chiedete pure -- verranno analizzati nel prossimo parsing. La lista andrà senz'altro ampliata ;-) Ovviamente, segnalazioni/patch sono ben accette :) Sono curioso di vedere i grafi! Buon divertimento :) David Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [SPAM][SPAM]Re: Vie con binari tramviari e corsie trasporto pubblico
Il 11 ottobre 2010 00:11, Alberto Nogaro bartosom...@yahoo.it ha scritto: Ci sarebbe questa proposta: http://wiki.openstreetmap.org/wiki/Proposed_features/Multiple_Tracks La proposta è interessante ma risolverebbe il problema solo in parte. Intanto perché da un default=2 per i binari tramviari (cosa non vera, ci sono anche le vie con un solo binario a senso unico), poi perché messa così considera solo le way taggate railway; le way miste highway + railway no. Tra l'altro questo, scopro ora, la supposizione che i binari tramviari vadano sempre in coppia è un default per il rendering di openstreetbrowser, ma IMHO è sbagliato. Qual è il luogo preposto per la segnalazione? :-) Magari aggiungendo una combinazione di lanes (per la parte highway) e tracks (per la parte railway) A proposito di mappe del trasporto pubblico, chi sa ogni quanto vengono aggiornati i siti come OPVNkarte, OSMtransport, etc? Possibile che abbiano aggiornamenti solo ogni 15 giorni o più? -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
L'ultima volta che avevo controllato non c'era una deadline già stabilita. Sicuramente si cercherà di parlare con il maggior numero possibile di persone. Inoltre, sicuramente, verranno create delle modellizzazioni per stabilire esattamente precedentemente al cambiamento quali dati rischiano di essere persi. Per quanto riguarda il trucchetto da te segnalato, è simile a quello che rende possibile il caricamento di dati google nel nostro database, ed è - legalmente e moralmente parlando - ugualmente sbagliato. Poichè si tratterebbe di violazione di copyright, penso, verranno prese tutte le precauzioni per evitarlo. Nulla vieta, però di rimappare la strada da zero o di convincere l'utente, prima del termine, ad accettare le nuove condizioni. Il 11/10/10, G Zambonigd.zamb...@tiscali.it ha scritto: Il 11/10/2010 09:53, Simone Saviolo ha scritto: Il 10 ottobre 2010 11:21, Fabio Alessandro Locati fabioloc...@gmail.com ha scritto: 2010/10/10 Niccolo Rigacci o...@rigacci.org: On Sun, Oct 10, 2010 at 10:46:23AM +0200, iiizio iiizio wrote: Sarebbe interessante sapere la percentuale di mappa che sopravviverebbe al cambio licenza più che la lista degli id. Non mi è chiaro se sono stati chiariti i seguenti dubbi: 1) I contributi derivati da oggetti creati da chi vuole rimanere con la vecchia licenza, rimangono con la vecchia licenza oppure vince la licenza dell'ultimo utente che ha fatto edit? Non ci sarà, alla fine, una 'nuova licenza' e una 'vecchia licenza' ci saranno (sempre se la procedura viene portata a termine) elementi con la nuova licenza o elementi eliminati. Secondo le attuali policy (ancora in discussione) tutti gli edits su un oggetto dopo un edit di un utente che non ha accettato la nuova licenza, verrebbero persi. Qualcuno sa quando succederà questo? Il rischio è quello di vedersi sparire le strade principali (quelle che c'erano già anni fa) perché gli utenti che le hanno importate non sono più contattabili / sono contrari al cambio di licenza. Se le cose stanno davvero così, una way creata da X e modificata venti volte da me dopo sarebbe eliminata perché io ho accettato la nuova licenza e X no. Ad ogni modo, fatta la legge trovato l'inganno: basta scaricarsi i dati attuali, e quando i dati non licenziati saranno eliminati li si ricaricano. Tutto il processo è un po' ridicolo... Tecnicamente è possibile, legalmente non credo. 2) Nel caso in cui debba valere la licenza originale, è davvero possibile risalire tutta la catena di edit per sapere se un elemento è contaminato dalla licenza CC-By-SA? La history completa è presente ;) Ecco, questo non è chiaro. La way viene eliminata ma il suo storico rimane presente? Da quello che ho capito io la history è presente adesso, il che permette di ricostruirne la storia. E' chiaro che poi non ci sarà nessuna history dei dati che andranno cancellati. -- Niccolo Rigacci Firenze - Italy Ciao, Simone Ciao Giuliano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Inviato dal mio dispositivo mobile Fabio Alessandro Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Fingerprint: 5525 8555 213C 19EB 25F2 A047 2AD2 BE67 0F01 CA61 Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Maperitive
2010/10/8 Federico Cozzi f.co...@gmail.com: 2010/10/8 Tiziano D'Angelo tiziano.dang...@gmail.com: Inoltre, come potete vedere da questo sito di test, la mappa contiene il solo territorio di Berlino. Come posso scaricare da OSM un'area entro certi confini definiti invece che un rettangolo? Ma è utile? Cioè: Maperitive è in grado di generare mappe di aree non rettangolari? E Openlayers sa gestire tileset non rettangolari? ovviamente non è cosí complicato: basta non avere dati oltre un certo poligono e la mappa non sembra rettangolare. Potresti tagliare con Osmosis la forma che ti interessa. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
Fabio Alessandro Locati wrote: Nulla vieta, però di rimappare la strada da zero o di convincere l'utente, prima del termine, ad accettare le nuove condizioni. Qui in Trentino abbiamo avuto, lo scorso anno, un utente che ha praticamente ritoccato tutto quello che gli capitava a tiro editando a spron battuto a tutte le ore del giorno e della notte. A spanne nella zona di Trento e dintorni non esiste quasi niente che non abbia toccato coi suoi edits (salvo gli edifici inseriti ultimamente con il ricalco da PCN). Il problema è che l'utente ha poi deciso di uscire da OSM: la sua utenza è stata rimossa ed i suoi edits taggati con un anonimo user_xx (ora non mi ricordo l'ID esatto). Ora mi chiedo: questo caso particolare come verrebbe trattato? Non sarebbe bello vedersi sparire sotto gli occhi mesi di lavoro (non parlo del mio, ma di quello dei mappatori che insistono principalmente su Trento). Fabrizio -- View this message in context: http://gis.638310.n2.nabble.com/utenti-che-hanno-confermato-la-nuova-licenza-e-CT-WAS-list-of-user-IDs-having-accepted-the-contributs-tp5618602p5622435.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Proposed tag: Flagpole
2010/10/8 Stefano Tampieri stefano.tampi...@gmail.com: scusate la domanda stupida, ma a cosa serve votare una cosa del genere quando i voti sono già tutti positivi ? come lo vorresti sapere senza votare? Non so come funzionano le votazioni però sarà approvato di sicuro alla scadenza o sbaglio ? si, se i voti sono sufficienti di numero (15 o 20, non mi riccordo). A proposito: questo tag viene anche applicato a bandiere che fanno parte di un edificio? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
On 10/10/10 Fabio Alessandro Locati wrote: 2) Nel caso in cui debba valere la licenza originale, è davvero possibile risalire tutta la catena di edit per sapere se un elemento è contaminato dalla licenza CC-By-SA? La history completa è presente ;) Questo e' falso: tutte le way di cui e' stato fatto uno split (e sono molte, con l'introduzione di rotonde, gli split fatti per aggiungere tag validi solo per un pezzo, quelli fatti per le route etc) hanno l'history completamente persa per una delle due parti. Lo stesso avviene per il caso (molto piu' raro pero') della combinazione di way. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
On 10/11/10 Simone Saviolo wrote: perché io ho accettato la nuova licenza e X no. Ad ogni modo, fatta la legge trovato l'inganno: basta scaricarsi i dati attuali, e quando i dati non licenziati saranno eliminati li si ricaricano. Tutto il processo è un po' ridicolo... Gia', quello che hai descritto e' proprio un inganno, se fatto in modo automatico: e' quasi impossibile che tutti gli edit successivi non siano in qualche modo dati derivati da quelli che sono stati eliminati e che quindi verrebbero reintrodotti con copyright cambiato. Per fare una cosa eticamente corretta serve controllare ad una ad una le modifiche successive. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
On 10/10/10 Fabio Alessandro Locati wrote: Sarebbe interessante sapere la percentuale di mappa che sopravviverebbe al cambio licenza più che la lista degli id. Assolutamente vero.. se fossero possibili statistiche di zona su questo sarebbe molto buono :) Questo purtroppo non e' possibile, dato che ogni volta che viene fatto lo split di una way l'history viene persa per uno dei due tratti. E' uno dei motivi per cui il cambio di licenza non e' praticabile senza violare il copyright dei contributor che non accetteranno, ma quelli che hanno proposto il cambio, per ignoranza e/o pressapochismo, hanno detto che se ne fregheranno del copyright. :( lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Proposed tag: Flagpole
2010/10/11 Stefano Tampieri stefano.tampi...@gmail.com: Il giorno 11 ottobre 2010 11:28, M∡rtin Koppenhoefer dieterdre...@gmail.com ha scritto: No Martin mi sono spiegato male, intendevo dire... visto che sono tutti positivi i voti e nessuno è negativo, pensavo fosse inutile votare, a meno che non ci fosse un quorum da raggiungere. Si, è sempre utile votare, perché anche se il quorum è già raggiunto esprimi comunche un supporto più forte con più voti... Ciao, Martin PS: Salvo il mio caso, che ho votato un giorno troppo tardi ;-) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
In effetti se si perde l'history per uno degli oggetti, è impossibile separare le due cose senza o epurare più dati del necessario o utilizzare dati di chi non ha accettato. Stefano Il giorno 11 ottobre 2010 11:35, Stefano Salvador stefano.salva...@gmail.com ha scritto: Questo purtroppo non e' possibile, dato che ogni volta che viene fatto lo split di una way l'history viene persa per uno dei due tratti. E' uno dei motivi per cui il cambio di licenza non e' praticabile senza violare il copyright dei contributor che non accetteranno, ma quelli che hanno proposto il cambio, per ignoranza e/o pressapochismo, hanno detto che se ne fregheranno del copyright. :( questa mi sembra un'affermazione abbastanza grave che personalmente non ho mai letto nelle varie discussioni (per lo meno mai da parte del core team di osm). hai per caso qualche riferimento in proposito ? Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
Il 11 ottobre 2010 11:23, Paolo Molaro lu...@oddwiz.org ha scritto: On 10/11/10 Simone Saviolo wrote: perché io ho accettato la nuova licenza e X no. Ad ogni modo, fatta la legge trovato l'inganno: basta scaricarsi i dati attuali, e quando i dati non licenziati saranno eliminati li si ricaricano. Tutto il processo è un po' ridicolo... Gia', quello che hai descritto e' proprio un inganno, se fatto in modo automatico: e' quasi impossibile che tutti gli edit successivi non siano in qualche modo dati derivati da quelli che sono stati eliminati e che quindi verrebbero reintrodotti con copyright cambiato. Ti sbagli: quando sono arrivato, un anno fa, a Vercelli e a Casale Monferrato c'erano le statali e appena qualche via di quelle principali. Ovviamente, io ho modificato quelle senza ricrearle da zero, per motivi tecnici (mantenere la history); nella maggior parte dei casi, tuttavia, si tratta di aver cambiato forma e posizione di queste vie, a volte anche in maniera eclatante (alcune avevano offset anche di più di 30 metri!). Lo stesso vale per alcune strade, soprattutto statali, che erano state importate da chissà dove e che ho pesantemente modificato (aggiunto punti, spostati altri, rimossi altri ancora). E sono d'accordo che non possa essere fatto in automatico, ma non mi va di veder sparire le strade più importanti solo perché qualcuno che ha abbandonato il progetto non ha accettato la licenza. Neppure mi va di passare un mucchio di tempo a disegnare cento kilometri di strade IMPORTANTI (tipo, quelle più usate dalla applicazioni di routing!) invece che a mappare altro! Per fare una cosa eticamente corretta serve controllare ad una ad una le modifiche successive. E come le controlli? Come puoi verificare che le modifiche successive non dipendano da quelle precedenti? Come puoi verificare che il mio Corso Italia non sia una semplice modifica di quello precedente? Tecnicamente, l'unica soluzione giusta sarebbe quella più assurda: quando editi una via, controlla lo storico, e, a meno che tutti gli editors non abbiano già accettato la licenza, *eliminala* e ridisegnala. Altrimenti, modificala pure, ma sappi che la tua modifica potrebbe andare persa fra due mesi. Il rimedio mi sembra peggio del male. lupus Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza
Il 11 ottobre 2010 10:57, Fabio Alessandro Locati fabioloc...@gmail.com ha scritto: Nulla vieta, però di rimappare la strada da zero Autostrade, statali, confini amministrativi, linee di costa, elementi naturali, import di massa sono solo esempi di oggetti vecchi o comunque importati da un solo utente. Se quel singolo utente non accetta il cambio di licenza, magari anche solo perché un certo import era stato fatto con un account creato ad hoc di cui si sono perse le credenziali (potrebbe succedere), quei dati *e le modifiche successive* vanno a farsi friggere. di convincere l'utente, prima del termine, ad accettare le nuove condizioni. Questo potrebbe non essere facile. Di solito gli utenti più vecchi sono quelli più politicamente coinvolti. Non è il nostro caso, per fortuna, ma pensa se Simone Cortesi, che ha importato autostrade, statali, confini amministrativi, fosse stato contrario al cambio di licenza. Scusate la provocazione, ma in campo FOSS queste discussioni diventano dispute sul filioque, e buona fortuna a chi vuole cercare di convincere un oppositore della nuova licenza. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [ANN] osmstats 1.0
On Mon, 11 Oct 2010 10:09:01 +0200, Simone Saviolo wrote: Il 10 ottobre 2010 18:45, David Paleino da...@debian.org ha scritto: Pur avendo azzoppato la parte più dinamica e simpatica della webapp (/graphs/, ossia la generazione dinamica di grafici), per motivi di performance dell'attuale server (o di poca ottimizzazione del codice, da vedere), sono lieto di annunciare OSMStats 1.0 http://osmstats.hanskalabs.net/ L'idea è di fare l'analisi settimanale dell'italy.osm in maniera automatizzata. Bello! Spero solo, visto che hai voluto rilasciare la versione 1.0 il 10/10/10, che non dobbiamo aspettare l'11/11/11 per avere il primo minor update ;-) Ahah, non credo, o, almeno, spero di no. :) L'intenzione è di riuscire ad abilitare la parte grafica quanto prima. L'interfaccia è sicuramente migliorabile, quindi non esitate a segnalare bug/richieste a [0]. A parte essere un po' spoglia, non mi sembra ci sia molto da fare. Bella! Beh, se qualche volenteroso volesse mettersi a smaneggiare con i template, il codice è lì :-D Attualmente l'analisi viene effettuata solamente su alcuni tags [1]. Nel caso vogliate altri tag, chiedete pure -- verranno analizzati nel prossimo parsing. La lista andrà senz'altro ampliata ;-) Ecco, apri un bug :) Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
2010/10/11 Stefano Salvador stefano.salva...@gmail.com: Questo purtroppo non e' possibile, dato che ogni volta che viene fatto lo split di una way l'history viene persa per uno dei due tratti. E' uno dei motivi per cui il cambio di licenza non e' praticabile senza violare il copyright dei contributor che non accetteranno, ma quelli che hanno proposto il cambio, per ignoranza e/o pressapochismo, hanno detto che se ne fregheranno del copyright. :( questa mi sembra un'affermazione abbastanza grave che personalmente non ho mai letto nelle varie discussioni (per lo meno mai da parte del core team di osm). hai per caso qualche riferimento in proposito ? http://wiki.openstreetmap.org/wiki/Questions_to_LWG_on_ODbL#Incomplete_History_for_Split_Ways Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
questa mi sembra un'affermazione abbastanza grave che personalmente non ho mai letto nelle varie discussioni (per lo meno mai da parte del core team di osm). hai per caso qualche riferimento in proposito ? http://wiki.openstreetmap.org/wiki/Questions_to_LWG_on_ODbL#Incomplete_History_for_Split_Ways ok, adesso capisco, non è che hanno detto che se ne fregano, hanno solo detto che è estramente difficile ricostruire l'history e l'approccio è che se qualcuno si lamenterà i dati verranno rimossi in seguito. Pare che abbiano consultato anche qualche legale in proposito. Sicuramente è un problema ma mi pare eccessivo affermare che se ne fregheranno. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
Il 11 ottobre 2010 12:48, Stefano Salvador stefano.salva...@gmail.com ha scritto: http://wiki.openstreetmap.org/wiki/Questions_to_LWG_on_ODbL#Incomplete_History_for_Split_Ways ok, adesso capisco, non è che hanno detto che se ne fregano, hanno solo detto che è estramente difficile ricostruire l'history e l'approccio è che se qualcuno si lamenterà i dati verranno rimossi in seguito. Pare che abbiano consultato anche qualche legale in proposito. Mi pare una posizione in linea con quello che si fa, da sempre, nel mondo del copyright (nonché con le possibilità tecniche che si hanno). Siccome è impossibile sapere per certo se si stanno violando diritti altrui, uno prende tutte le precauzioni possibili ed un metodo di lavoro che miri ad evitare violazioni. Nel caso qualcuno si lamenti di una violazione, si cerca un accordo e si agisce di conseguenza. D'altro canto, anche nel mondo del copyright (ma mi spingerei a dire nel mondo del diritto tutto) spetta a chi detiene un diritto lamentarsi delle violazioni altrui e, al limite, anche dimostrare che vi sia la violazione e/o il dolo. -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
Pure io ho accettato oggi, non sapevo fosse cosi' importante da perdere dati. Se facevano qualcosa sulla pagina iniziale con un bel popup centrale forse era meglio. Cosi' di sicuro nessuno sa dove sta se non glielo dicono. Il 10/10/2010 13:34, Fabio Alessandro Locati ha scritto: 2010/10/10 alessioklava...@gmail.com: Ma come faccio a dare la mia desione alla nuova licenza? Verrò contattato via mail? Basta collegarsi a openstreetmap.org - tuo nome in alto a dx - my settings su quella pagina troverai indicata la domanda ;) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] licenza nel Wiki
Ho trovato su questa pagina: http://wiki.openstreetmap.org/wiki/IT:ODbL/We_Are_Changing_The_License questo paragrafo (alla fine), che non è completamente tradotto: Se la Fondazione non riesce a pubblicare solo sotto una licenza libera e aperta, ha rotto il suo contratto con te. Una copia dei dati esistenti può essere realizzata e diffusa da un diverso (body)??. secondovoi si potrebbe scrivere ente per body? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] licenza nel Wiki
Il 11 ottobre 2010 13:25, M∡rtin Koppenhoefer dieterdre...@gmail.com ha scritto: Se la Fondazione non riesce a pubblicare solo sotto una licenza libera e aperta, ha rotto il suo contratto con te. Una copia dei dati esistenti può essere realizzata e diffusa da un diverso (body)??. secondovoi si potrebbe scrivere ente per body? da un diverso soggetto? -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
Purtoppo è vero che il non-accettare comporta grossi rischi per il progetto. La (non)pubblicità che per ora (non) si vede è dovuta alla fase della transizione in cui siamo. Già da ieri al login e sul wiki c'è un box in alto che parla della transizione. Sono sicuro che nelle prossime fasi sarà sempre più difficile 'non notare' la cosa Il 11/10/10, Bighibi...@ngi.it ha scritto: Pure io ho accettato oggi, non sapevo fosse cosi' importante da perdere dati. Se facevano qualcosa sulla pagina iniziale con un bel popup centrale forse era meglio. Cosi' di sicuro nessuno sa dove sta se non glielo dicono. Il 10/10/2010 13:34, Fabio Alessandro Locati ha scritto: 2010/10/10 alessioklava...@gmail.com: Ma come faccio a dare la mia desione alla nuova licenza? Verrò contattato via mail? Basta collegarsi a openstreetmap.org - tuo nome in alto a dx - my settings su quella pagina troverai indicata la domanda ;) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Inviato dal mio dispositivo mobile Fabio Alessandro Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Fingerprint: 5525 8555 213C 19EB 25F2 A047 2AD2 BE67 0F01 CA61 Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
Premetto che ho accettato la nuova licenza (il mio userid è in lista). Il metodo di procedere per la cancellazione dei dati mi sembra un cagata pazzesca. Prendiamo l'esempio citato da Fabio: se io sono l'utente a e non ho accettato la nuova licenza (erché sono uscito dal progetto e non sto più seguendo i forum) viene a predersi tutto il lavoro fatto dai mappers successivi. In questo momento il mio lavoro è di sistemazione dei dettagli della mappa nella mia zona. Di reinserire le statali solo perché qualcuno anni fa le ha inserite, sono state editate successivamente e poi se ne è andato sinceramente è un lavoro che mi piace poco, anche perché bisogna appena andare a capire cosa è stato cancellato/modificato e come. Sarei il primo a farmi una copia del planet prima e dopo il cambio di licenza e fare un bel script di ripristino automatico, almeno per la mia zona. Questo perché va bene la licenza, va bene la filosofia oss, va bene tutto quello che volete, però se io sono l'editor h ho il diritto che il mio lavoro resti così com'è e non venga cancellato. Scusate lo sfogo, però se dopo il passaggio alla nuova licenza ci saranno vistose perdite di dati non so se continuerò a dedicare parte del mio tempo libero ad un progetto per cui nutro, nonostante tutto, grandi speranze. Stefano Il 10/10/2010 19:14, Fabio Alessandro Locati ha scritto: purtroppo è vero quello che dici. comunque considera che se un nodo ha la seguente history: a-b-c-d-e-f-g-h-i e tutti gli editors hanno accettato il ct tranne quello dell'h, solo gli edits h ed i verranno persi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
Il 11 ottobre 2010 14:24, Stefano de Fabris defa...@gmail.com ha scritto: Premetto che ho accettato la nuova licenza (il mio userid è in lista). Il metodo di procedere per la cancellazione dei dati mi sembra un cagata pazzesca. Prendiamo l'esempio citato da Fabio: se io sono l'utente a e non ho accettato la nuova licenza (erché sono uscito dal progetto e non sto più seguendo i forum) viene a predersi tutto il lavoro fatto dai mappers successivi. In questo momento il mio lavoro è di sistemazione dei dettagli della mappa nella mia zona. Di reinserire le statali solo perché qualcuno anni fa le ha inserite, sono state editate successivamente e poi se ne è andato sinceramente è un lavoro che mi piace poco, anche perché bisogna appena andare a capire cosa è stato cancellato/modificato e come. Sarei il primo a farmi una copia del planet prima e dopo il cambio di licenza e fare un bel script di ripristino automatico, almeno per la mia zona. Questo perché va bene la licenza, va bene la filosofia oss, va bene tutto quello che volete, però se io sono l'editor h ho il diritto che il mio lavoro resti così com'è e non venga cancellato. Scusate lo sfogo, però se dopo il passaggio alla nuova licenza ci saranno vistose perdite di dati non so se continuerò a dedicare parte del mio tempo libero ad un progetto per cui nutro, nonostante tutto, grandi speranze. Per fortuna, lo scenario non sembra molto realistico, almeno qua in Italia. Per fare un'analisi seria, bisognerebbe scaricarsi l'osm aggiornato di una zona, prendersi lo storico di ogni relazione, ogni nodo e ogni way, guardare qual è il più recente edit di un utente che non ha ancora accettato ed eliminare gli edit successivi, quindi valutare il danno. Non penso sia enorme, ma senz'altro alcune delle cose che diamo per scontate in una mappa potrebbero andar perse. Stefano Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Vie con binari tramviari e corsie trasporto pubblico
2010/10/10 Michael von Glasow mich...@vonglasow.com: On 01/-10/-28163 08:59 PM, Maurizio Daniele wrote: Per quanto riguarda i binari: anche se spesso si incontra una singola way taggata highway=*; railway=tram, tale modo di taggare è sconsigliato perché diverrebbe impossibile aggiungere degli eventuali altri tag legati ai soli binari oppure alla sola strada asfaltata. +1 Due o più binari paralleli possono essere rappresentati da una singola way. Si, ma è da considerare preliminare. Una mappa finita dovrebbe avere ogni singolo binario come singolo way. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Vie con binari tramviari e corsie trasporto pubblico
2010/10/10 Federico Cozzi f.co...@gmail.com: 2010/10/10 Michael von Glasow mich...@vonglasow.com: Esempio [1]: metterei una way taggata highway=*;oneway=no (quest'ulteriore non è strettamente necessario), poi un'altra taggata railway=tram usando gli stessi punti. Non sono d'accordo, la way è una sola e i tag vanno applicati alla medesima way. non sono d'accordo: sono 2 way (una macchina non usera i binari ed un tram non puo usare la strada) che coincidono approssimativamente sulla stessa posizione. Altrimenti ad es. una pista ciclabile dipinta sulla carreggiata dovrebbe generare una seconda way: la prima highway=unclassified, la seconda highway=cycleway. (e invece è highway=unclassified + cycleway=lane) sarebbe meglio, perché con cycleway=lane si creano tanti problemi (esempio: dove si trova la lane: a destra o a sinistra della strada?) e la situazione ai incrocci non diventa chiara. Ovviamente la soluzione non puo essere di mappare highway=cycleway esplicitamente (perché il significato sarebbe quello di 2 way fisicamente separate), ma dovrebbe coinvolgere qualche nuova invenzione tipo lanes (corsie). Fortunatamente il problema railway / highway è meno difficile. Se, seguendo questo schema, qualche tag diventa ambiguo è un errore del tag (esempio: fee=yes) -1 Ad es. width si applica alla way fisica, indipendentemente dal fatto che sia highway o railway. a si? tu dici i binari di un tram su una strada hanno una width uguale a quella della strada? Mi sembra un opinione particolare. Quello di cui forse sente bisogno Maurizio è un ipotetico tag railway_tracks=2 che indichi che quella railway è composta da due binari paralleli si usa tracks=numero, ma è in qualche modo sbagliato, perché 2 percorsi fisicamente separati (come 2 binari paralleli) si devono mappare separatamente. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Vie con binari tramviari e corsie trasporto pubblico
Il 11 ottobre 2010 14:08, M∡rtin Koppenhoefer dieterdre...@gmail.com ha scritto: non sono d'accordo: sono 2 way (una macchina non usera i binari ed un tram non puo usare la strada) che coincidono approssimativamente sulla stessa posizione. si ma geograficamente sono lo stesso elemento ;-) ciao, Martin ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Vie con binari tramviari e corsie trasporto pubblico
2010/10/10 Maurizio Daniele maurizio.dani...@gmail.com: Il giorno dom, 10/10/2010 alle 16.22 +0200, Federico Cozzi ha scritto: Anche. Potrebbe essere un'idea, ma resto dell'idea che due binari, proprio perché fisicamente e rigidamente separati, dovrebbero essere mappati con due way +1 a senso unico (il che varrebbe anche per le ferrovie, non solo per i tram). -1 il senso unico per le ferrovie non è valido: i treni vano avanti e indietro sullo stesso binario (e alle volte si sorpassono due treni opposti a sinistra). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [ANN] osmstats 1.0
2010/10/10 David Paleino da...@debian.org: http://osmstats.hanskalabs.net/ Buon divertimento :) Grazie David, bellissimo lavoro. Dobbiamo inserire più indirizzi ;-) Non so per quanto sia possibile (o già integrato): lasciare fuori (forse opzionalmente) gli edit di bots (changeset taggati con bot=yes) ed importazioni. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Erboristerie
2010/10/11 Bighi bi...@ngi.it: Rinnovo la domanda visto che si e' persa tra le Enoteche. Il 08/10/2010 14:37, Bighi ha scritto: Consultando il wiki non capisco se le erboristerie vanno taggate come shop = organic o come le farmacie o chemist? Magari poi qualcuno puo' modificare sul wiki direi che vada bene shop=* se ti decidi ti mettergli come farmacie aggiungerei dispensing=no. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] utenti che hanno confermato la nuova licenza (e CT) WAS list of user IDs having accepted the contributor terms
On 11/10/2010 14:35, Simone Saviolo wrote: Per fortuna, lo scenario non sembra molto realistico, almeno qua in Italia. Per fare un'analisi seria, bisognerebbe scaricarsi l'osm aggiornato di una zona, prendersi lo storico di ogni relazione, ogni nodo e ogni way, guardare qual è il più recente edit di un utente che non ha ancora accettato ed eliminare gli edit successivi, quindi valutare il danno. Non penso sia enorme, ma senz'altro alcune delle cose che diamo per scontate in una mappa potrebbero andar perse. Esiste un tool? Quando avverrà il passaggio? Jacopo -- Blog: http://jg.homelinux.net/blog Root: http://jg.homelinux.net/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Problema nell'accettazione della nuova licenza
Ciao a tutti, innanzitutto mi presento: mi chiamo Matteo, sono di Como e sto mappando da circa due anni. Ho mappato principalmente Como e dintorni e parte dell'Alta Valtellina. Sono iscritto da tanto alla maling list italiana di openstreetmap ma non vi ho mai scritto. Io avrei un problema con l'accettazione della nuova licenza; mi loggo sul sito, clicco sul mio nick name, vado alla pagina delle impostazioni e trovo: Please follow this link at your convenience to review and accept the new Contributor Terms. Clicco il link e vengo portato alla pagina per l'attivazione dell'account (Create a User Account) con il seguente errore generato: New email does not appear to be a valid e-mail address Come devo fare? Grazie a tutti per l'attenzione! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
