Re: [Talk-it] Taggare questa stradine
On 02/09/13 19:19, Martin Koppenhoefer wrote: 2013/9/2 emmexx emm...@tiscalinet.it mailto:emm...@tiscalinet.it Ancora una volta: highway=service con service=alley indica i vialetti di servizio, non la rete di strade medievali. puoi dare una definizione di vialetto di servizio, soprattutto cosa esclude? Leggendo la pagina di service, c'è scritto anche: a narrow road or path between properties (per service=alley). between properties esclude percorsi ce si trovano sul fondo privato, quindi è suolo pubblico, o come lo leggete? Non ci sono altri indicazioni sull'uso di alley. Il wiki dice appunto che service è per strade di accesso (vedi: http://wiki.openstreetmap.org/wiki/Key:highway ) cosa nel caso di alley non vale. ciao, Martin Ciao a tutti, suggerisco come regola generale: se ha un nome, non è service, ma (di solito) residential o unclassified. Se non ha un nome, ma le altre strade in comune ce l'hanno, può essere service. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] highway=abandoned
Hallo, ich meine, es gab schon einige Diskussionen darüber, ob man historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was vor Ort noch real existiert. (Ausnahmen gibt es vielleicht noch für Objekte, die im Bau oder geplant sind, also in absehbarer Zeit echte Objekte werden.) Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag daran hängen, das tut nicht weiter weh. Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein Neubaugebiet ist, sind das nur noch historische Daten. Mag sein, dass auch die interessant sind, aber das gehört IMHO dann nicht mehr in OSM. Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags, von wann bis wann das Objekt existierte... Grüße Michael On 21/08/13 13:30, tumsi wrote: Hallo zusammen, Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden. Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich finde das ganze etwas seltsam, vor allem, wenn man vor Ort nicht einmal mehr erkennen kann, dass dort irgendwann einmal Straßen existierten! Welchen Wert hat das ganze in der Datenbank? Ich mappe doch auch keine Gebäude, die abgerissen wurden und an deren Stelle nun neue Gebäude stehen... Wie seht ihr das? Viele Grüße, Constanze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Posizionamento Smartphone Giroscopio ecc
On 13/08/13 20:31, Alessandro wrote: Anch'io ho lo stesso dubbio di Giacomo: un giroscopio vero e proprio su un telefono cellulare penso scaricherebbe la batteria in breve tempo. Alessandro Ale_zena_IT Il giorno Tue, 13 Aug 2013 12:52:49 +0200 Giacomo Boschi gwil...@gmail.com ha scritto: Il 11/08/2013 13:20, Salemme Guido ha scritto: adesso io ho un Galaxy Nexus dotato di giroscopio accellerometri e gps (anche barometro per l'altezza) Considerazione a latere: sicuro si tratti di giroscopi? Che io sappia si tratta di rivelatori di campo magnetico che funzionano da bussola. Per quanto ne sappia, i Nexus (almeno il Nexus S e il Galaxy Nexus) hanno sia dei veri e propri giroscopi che dei rilevatori magnetici. I rilevatori magnetici nel Nexus S hanno degli errori grossissimi, in modo tale da rendere quasi inutilizzabile la bussola magnetica. Non servono quasi a niente se non vengono calibrati immediamente prima di usarli, e rimangono comunque sensibili a campi magnetici od oggetti metallici. Se volete provarlo, scaricatevi Osmand, che visualizza la direzione della bussola magnetica, e confrontate... spesso vi resulta un errore di 90° e di più... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Posizionamento Smartphone Giroscopio ecc
On 11/08/13 18:50, Aury88 wrote: in quel caso, una volta ripreso il segnale e fatto il confronto tra la posizione stimata tramite sistemi inerziali e posizione gps penso possa essere fattibile l'applicazione di una correzione lineare postuma :) -- View this message in context: http://gis.19327.n5.nabble.com/Posizionamento-Smartphone-Giroscopio-ecc-tp5773227p5773245.html Sent from the Italy General mailing list archive at Nabble.com. Sto lavorando su una cosa del genere, con l'obiettivo principale di far funzionare la navigazione anche nelle gallerie stradali. Come è stato detto, pero, un problema principale è che gli errori si accumulano, così tale navigazione inerziale sarebbe utile solo per tratti brevi. Con uno smartphone un'altra difficolta è di individuarne l'orientamento rispetto alla terra. I dati dell'accelerometro (che infatti ci da la somma di accelerazione e gravitazione) sono utili solo se il dispositivo non è soggetto a nessuna accelerazione, di solito quando è fermo. Poi, ovviamente, l'orientazione può cambiare e bisogna ricalibrare l'orientamento. Se questo avviene in assenza di un segnale GPS, può introdurre grossi errori. Usando un navigatore, però, l'errore so potrebbe ridurre correggendo la posizione così ottenuta in base ai dati della mappa. So che nell'industria si fanno deli rafforzi simili per integrare tale funzionalità nella prossima generazione di chip GPS. Quello sarà in hardware anziché in software e dovrebbe funzionare con un qualsiasi pezzo di software. Per l'utente l'unica differenza sarebbe che si ottiene una posizione anche entrando in un traforo o un parcheggio sotteraneo. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Autokennzeichen
On 09/08/13 21:57, Christian Hauer wrote: Am 09.08.2013 20:24, schrieb Martin Koppenhoefer: in Italien schon länger nicht mehr, da bedeuten die ersten beiden Stellen das Jahr der Erstzulassung Ok ok, ich nehm ja Italien schon zurück ;) Italien und Frankreich haben inzwischen das gleiche Schema: Nummern der Form AA 123 BB, die fortlaufend vergeben werden (so dass aus den ersten zwei Buchstaben auf das Zulassungsdatum geschlossen werden kann; in Italien wechseln die ersten zwei Buchstaben im Schnitt alle zwei Monate, in Frankreich geht es etwas schneller). Das Provinz- oder Départementkürzel (2 Buchstaben in Italien, 2 Ziffern in Frankreich) kann im rechten Streifen stehen, ist aber freiwillig und kann irgendeines sein, nicht notwendigerweise das eigene. Sowohl in Italien als auch in Frankreich werden diese Kürzel aber weiterhin benutzt, u.a. für Adressangaben. In Italien findet man in Anschriften z.B. häufig Ortsangaben wie 20094 Corsico (MI) (in dem Fall ein Ort in der Provinz Milano). In Frankreich sind die ersten zwei Ziffern der Postleitzahl mit der Départementnummer identisch, in Text findet man zur groben geographischen Einordnung zum Teil Ortsangaben wie Modane (73) (d.h. im Département Savoie, Nr. 73). Etwa ein Viertel der EU/EEA-Staaten hatte nie eine regionale Zuordnung der Autokennzeichen, ein weiteres Viertel hat sie mittlerweile abgeschafft bzw. denkt in einem Fall über eine Einführung nach, etwa die Hälfte hat es in Gebrauch, wobei es von Staat zu Staat Unterschiede gibt, ob bei Verkauf der Fahrzeugs oder Umzug das Kennzeichen gewechselt wird oder nicht. In den Staaten, die eine regionale Zuordnung haben oder früher hatten, werden die Kürzel oft auch anderweitig verwendet. Beispielsweise verwenden in Deutschland auch Tierärzte das Kreiskürzel in ihren Kennummern (Katzenbesitzer, schaut euch mal das Tattoo eurer Lieblinge an, sofern vorhanden). Der langen Rede kurzer Sinn: warum nehmen wir dieses Kürzel nicht einfach in den ref-Tag der jeweiligen Verwaltungseinheit auf? Die Litauer machen das schon (allerdings sind die Kürzel in OSM zweistellig und nicht mit denen im Kfz-Kennzeichen identisch). Die Amerikaner machen das gleiche mit den Kürzeln für ihre Bundesstaaten. In kleineren Zooms wird das dann auch gerendert und nimmt weniger Platz weg als der volle Name. Grüße Michael PS: Kfz-Kennzeichenschemata im einzelnen: Österreich: Bezirkskürzel (1-2 Buchstaben) am Anfang der Autonummer Bulgarien: Provinzkürzel (1-2 Buchstaben) am Anfang der Nummer Kroatien: Provinzkürzel (2 Buchstaben) am Anfang der Nummer Zypern: Autonummern ohne regionale Zuordnung Tschechien: 2. Zeichen (1 Buchstabe) der Nummer bezeichnet die Region (Kraj), z.B. 1A2-3456 für Prag (A) Estland: 1. Buchstabe bezeichnet die Region, z.B. 123 ABC für Tallinn (A) Finnland: heute keine regionale Zuordnung mehr, früher (1972-1989) bezeichnete der 1. Buchstabe die Region Griechenland: Präfekturkürzel (2 Buchstaben) am Anfang der Nummer Ungarn: heute keine regionale Zuordnung, aber es gibt Pläne, diese einzuführen Irland: Grafschaftskürzel (1-2 Buchstaben) zwischen den beiden Zifferngruppen Litauen: heute keine regionale Zuordnung mehr, bis 2003 gab der 2. Buchstabe die Region (Apskritis) an, z.B. CPN 183 für Panevėžys (P) Norwegen: die ersten zwei Stellen identifizieren die Stadt, meist mehrere Kürzel pro Stadt Polen: 2-3 Buchstaben Bezirkskürzel, von denen der erste die Woiwodschaft identifiziert, am Anfang der Nummer, z.B. SZY 1234 für Żywiec, Woiwodschaft Śląskie (S) Portugal: nur für Anhänger und Exportfahrzeuge, 1-2 Buchstaben für die Zulassungsstelle, z.B. VS-08-15 oder 08-15-VS für Viseu Rumänien: Bezirkskürzel (1-2 Buchstaben) am Anfang der Nummer Slowakei: Bezirkskürzel (2 Buchstaben) am Anfang der Nummer. Einige Städte bestehen aus mehreren Bezirken, vergeben aber nur eine Nummer (Ausnahme Bratislava, wo der Nummernvorrat für BA bereits ausgeschöpft ist und daher zusätzlich BL verwendet wird.) Slowenien; Bezirkskürzel (2 Buchstaben) am Anfang der Nummer Spanien; heute keine regionale Zuordnung mehr, vor 2000 Provinzkürzel (1-2 Buchstaben) am Anfang der Nummer Schweiz: Kantonskürzel (2 Buchstaben) am Anfang der Nummer UK: seit 2001 1. Buchstabe Region, 2. Buchstabe Zulassungsstelle. Der Regionsbuchstabe ist eineindeutig, Zulassungsstellen haben mehrere Kürzel. Z.B. LA51BCD und LB51FGH für Wimbledon (London), Belgien, Dänemark, Lettland, Liechtenstein, Luxemburg, Malta, Niederlande, Schweden: keine regionale Zuordnung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] tagging di aree
On 07/08/13 11:51, Martin Koppenhoefer wrote: 2013/8/6 Michael von Glasow mich...@vonglasow.com mailto:mich...@vonglasow.com Hmm... per rappresentare sia il gruppo che ogni singolo lago, potremmo mappare ogni lago come poligono, il quale tagghiamo natural=water, name=nome del lago. Poi potremmo creare una relazione type=multipolygon, natural=water, name=nome del gruppo ed aggiungere a quella i laghi con il ruolo outer. Che ne pensate? ma in questo modo non indichi (o solo in maniera generica) di cosa si tratta. Suggerisco di aggiungere anche il tag water: http://wiki.openstreetmap.org/wiki/Key:water Quindi per il singolo lago sarebbe water=lake, invece per il gruppo di laghi non c'è (credo) ancora una proposta. Se tagghiamo anche questo gruppo con natural=water credo che andremmo a creare un doppione (a livello di semantica, perché abbiamo 2 oggetti con natural=water per la stessa area). Non ripeterei natural=water sulla relazione per il gruppo di laghi, ma metterei un tag per indicare che si tratta di un gruppo di laghi (per esempio natural=group_of_lakes) water=lake per i laghi va bene secondo me. Per quanto riguarda i doppioni, non credo che ci siano dei problemi troppo gravi nelle applicazioni: Una ricerca per nome troverebbe sia il gruppo che i laghi singoli. Un'elenco di tutti gli oggetti in zona elencerebbe sia il gruppo che i laghi singoli - anche questo, credo, ci sta. Un renderizzatore metterebbe un'etichetta per il gruppo e una per ogni lago con nome proprio (a meno che non si saltino alcune causa sovrapposizione), anche questo va bene. Per i laghi stessi verrebbero renderizzate due poligoni identici sovrapposti - questo non fa niente purché non siano semitrasparenti... Per quello hai probabilmente ragione che la soluzione più pulita sarebbe di introdurre un tag specifico. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tagging di aree
On 06/08/13 12:19, Martin Koppenhoefer wrote: Il giorno 05/ago/2013, alle ore 21:03, Yuri D'Elia wav...@users.sourceforge.net ha scritto: Vorrei taggare un gruppo di laghi con il loro nome: Da notare che a volte i laghi hanno un nome proprio (pur facendo parte dello stesso gruppo), e questa informazione non va tolta. Come taggare un informazione del genere? multipolygon con name che comprende i laghi? si, più qualche tag per indicare di cosa si tratta (a cosa si riferisce il name). Per me una chiave da usare sarebbe natural (visto che si tratta di un feature topografico). Una relation di qualche tipo contenente le 3 aree? appunto, sarebbe un multipoligono, no? Hmm... per rappresentare sia il gruppo che ogni singolo lago, potremmo mappare ogni lago come poligono, il quale tagghiamo natural=water, name=nome del lago. Poi potremmo creare una relazione type=multipolygon, natural=water, name=nome del gruppo ed aggiungere a quella i laghi con il ruolo outer. Che ne pensate? Una questione analoga riguarda i nomi delle valli. Sempre alle alte scale sarebbe bello conoscere il nome della valle. Anche al riguardo non ho trovato niente di ufficiale. si, in realtà per una valle la situazione è diversa però, perché lì si tratta di una area non chiaramente delimitata, mentre un lago al solito è facilmente individuabile. Terrei fuori il discorso le valli per il momento (come anche altre entità geografiche estese, per dire le Alpi, il pacifico, tutto oggetti che hanno senso su una mappa, ma dove il modello di OSM non è molto adatto per la rappresentazione. C'era un'idea per rappresentare aree senza limiti chiari con una relazione di una serie di oggetti (nodi, ways) che sono sicuramente contenute (e forse anche altri che sono sicuramente fuori, ed il software potrebbe poi farsi un idea (tramite convex hull o simile) dell'ubicazione ed estensione di quel area (e sarebbe un tipo di oggetto abbastanza stabile: la cancellazione di un oggetto contenuto non renderebbe tutto l'oggetto inutilizzabile, come nel caso di un buco in una relazione multipoligono). Può andare bene per valli grandi, ma per quelli piccoli diventa più difficile, perche spesso no ci sono oggetti all'interno (o troppo pochi oggetti). Ho incontrato alcuni casi in questa zona [1], laddove ho creato dei nodi con place=locality, ma forse non è la soluzione perfetta. Per la renderizzazione di tali casi c'era un'immagine della settimana poco tempo fa [2], che spega anche come individuare le dimensioni dell'etichetta. Qui la presunzione è che l'area sia mappata come poligono. Nel esempio presente, sembra che per delimitare una catena di montagni si siano utilizzate le basi delle valli circondanti. In analogia, per una valle si potrebbero utilizzare le creste di montagne delimitanti - ovvero, come approccio più grezzo, una linea collegando le cime. ciao Michael [1] http://www.openstreetmap.org/#map=17/47.14438/10.22339 [2] http://wiki.openstreetmap.org/wiki/File:Maxbe-stubaier-beschriftung_en.png ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Pseudonamen
On 30/06/13 13:39, Wilhelm Spickermann wrote: Spricht etwas dagegen, solche Texte von name nach description zu verschieben? Ja, so global schon (sprich: Nein, außer...) Für die Relationen legt die Beschreibung der Relationen die Bedeutung der Relationstags fest. So ist im Public Traffic Proposal für den Namen von Linienvarianten angegeben: verkehrsmittel nr doppelpunkt from doppelpfeil to also z.B. Bus 17: Paris =Pelkum Das sollte man nicht ändern, obwohl es ziemlich sicher so nicht woanders benutzt wird. Aber ansonsten bin ich sehr dafür. Im Prinzip ja... aber Erfahrung zeigt, dass Relationen in JOSM in der Relationen-Liste schwer wiederzufinden sind. Da hilft ein eindeutiger name-Tag (description wird in JOSM 5990 nicht ausgewertet). Zugegeben, das ist nur ein Workaround... besser wäre es, in JOSM die Darstellung der Relationen-Liste zu überarbeiten. Etwa so: - Icon für type und ggf. auch Untertyp (z.B. Bus-Icon für type=route; route=bus oder verschiedene Verkehrszeichen für verschiedene type=restriction) - Typ in Textform nur, wenn kein Icon definiert ist (spart Platz für bekannte Typen) - Geeignete Beschreibung. Im allgemeinen Fall eine Kombination aus ref und name; falls diese leer sind, description, ggf. noch weitere. Für einige Typen ist ein abweichendes Schema besser, etwa für Nahverkehrslinien name/from/to. Das ganze mit Styles anpassbar - damit würde sich der Use-Case für etliche solche Pseudonamen schon relativieren. Mit Pseudonamen an anderen Objekten wäre ich strenger... etwa München-Augsburg an einem Bahngleis oder Nummern von Tramlinien direkt am Gleis. Solche Informationen gehören eher in den description-Tag oder in eine route-Relation. Hier würde es evtl. helfen, wenn der Mapnik-Kartenstil nur noch für bestimmte Objekttypen (u.a. highway=*, place=*, building=* und alles, was ein POI-Icon hat) den Namen rendern würde - damit würde der Anreiz des Tagging für den Renderer wegfallen. Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie sinnvoll im Thread antworten? (Inhalticher Betreff: Open Data)
On 01/21/2013 03:37 PM, Bernd Wurst wrote: Hallo. Am 21.01.2013 15:18, schrieb Wolfgang Barth: kann man auf einen Einzelbeitrag hier in der Mailingliste antworten, auch wenn man nur die Zusammenfassungen bezieht? Nein, das geht prinzipbedingt nicht. Wenn diese Nachricht hier richtig in den Thread einsortiert wird, dann geht das. Die Zusammenfassung enthält alle Nachrichten als Attachment; einfach die passende Nachricht öffnen und mit reply to list darauf antworten. Das mache ich immer so, und wenn ich meine früheren Postings anschaue, hat das auch immer funktioniert. Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ODBL und bekannte Vandalen-Accounts
Hallo Liste, was passiert eigentlich im Zuge der ODBL-Umstellung mit den Daten, die von Vandalen à la lmaa-du-osm-korinthenkacker, hasse-osm-korinthenkacker usw. angefasst wurden? Soweit ich weiß, hat der ja gern ganze Kartenbereiche gelöscht und nahezu unverändert wieder eingefügt. Damit existiert jetzt ein Haufen gültiger, korrekter Objekte, die in V1 von ihm erstellt wurden. CT und ODBL hat er natürlich abgelehnt, und sowohl sein Verhalten als auch die Kommentare auf seinen Userseiten lassen nicht erwarten, dass er sie noch akzeptieren wird. Als Folge davon gibt es Bereiche auf der Karte, die komplett rot sind. Was passiert nach der Umstellung mit solchen Edits? Kann man für derartige Fälle pauschal davon ausgehen, dass die Daten nicht von ihm stammen und seine Edits als ODBL-clean markieren? Oder wie verhindern wir, dass durch derartigen Vandalismus ganze Gebiete von der Karte verschwinden? Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL und bekannte Vandalen-Accounts
SimonPoole wrote Am 09.03.2012 10:48, schrieb Falk Zscheile: Ich war der Meinung, dass hier auf der Liste mal davon die Rede war, dass die Edits dieses Users übernommen werden, weil sie nicht auf eigener Leistung des Mappers beruhen. Habe ich das falsch in Erinnerung? Ich hab diverse Sachen von ihm angeschaut und meiner Meinung nach ist das wohl kaum möglich. Er hat ja nicht nur Unsinn gemacht, also müsste man das alles händisch rausfiltern. Ob er wirklich irgendetwas Sinnvolles gemacht hat, dürfte schwer herauszufinden sein. Wie bereits erwähnt, hat er gern mal ganze Viertel gelöscht und wieder eingefügt, wohl, damit es auf den ersten Blick so aussieht, als wären seine Beiträge legitim. Ansonsten hat er gern mal Tags verbogen, etwa name=U-Bahn für U-Bahn-Stationen und dergleichen. Gibt es wirklich etwas, das auf seiner eigenen Leistung beruht? SimonPoole wrote Siehe http://cleanmap.poole.ch/?zoom=16lat=48.0854lon=11.50844layers=000B wenn ich in der Area auf Cleanmap gehe, schaut das ziemlich übel aus... die meisten Straßen fehlen. So, wie es auschaut, hat unser Freund wohl mehrere Accounts. Wenn er nun mit Account A Dinge gelöscht hat, die er danach mit Account B wieder angelegt hat, und für Account A die CTs akzeptiert, aber für Account B ablehnt, dann haben wir ein Problem... die Löschungen bleiben, die neuen Objekte nicht, im Endeffekt verlieren wir damit Daten. SimonPoole wrote einfach vom gelöschten remappen (lmaa* war ja die Hauptmotivation für den Layer). Warum übernehmen wir die Daten dann nicht einfach direkt? Urheberrechtlich kommt es auf das gleiche heraus, ob wir Daten beibehalten oder ob wir sie löschen, aber dann von den gelöschten Daten remappen. So oder so bilden lmaa*'s Daten die Grundlage und die neuen Daten erben damit jedwedes Urheberrecht von diesen. Das alles per Hand neu anzulegen, ist ein ziemlicher Aufwand - es ist mit Sicherheit einfacher, erstmal alles zu übernehmen und nur ungültige oder falsche Informationen zu korrigieren. Dieser Ansatz hat ja bislang auch funktioniert. Daher denke ich, wir sollten erst einmal klären, ob wir davon ausgehen können, dass dieser Benutzer Urheberrecht an seinen Edits beanspruchen kann (will heißen: eigene Leistung). Wenn nein: alle Changes als ODBL-clean betrachten. Wenn ja, können wir seine Edits nicht direkt übernehmen. Dann heißt es, überall dort, wo er Objekte angelegt hat, zu schauen, ob es dort alte Objekte gibt, die gelöscht wurden. (Möglicherweise unter einem anderen Account, der die CTs akzeptiert hat.) Dann sollten wir uns die dafür verwendeten Accounts genauer anschauen und schauen, was passiert, wenn wir diese Löschungen rückgängig machen. -- View this message in context: http://gis.19327.n5.nabble.com/ODBL-und-bekannte-Vandalen-Accounts-tp5550019p5550200.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-it] Waze?
Ho appena letto i termini di servizio: Gli utenti danno un permesso permanente a Waze di utilizzare i loro dati a quasi qualsiasi scopo. Dai termini di servizio sembra che Waze utilizzi anche dati di altri fonti -- se una di queste fonti dovesse avere una licenza che non è compatibile con OSM, non si potrebbero unire questi dati con quelli di OSM. Se Waze utilizzasse solo i contributi dei propri utenti più i dati di OSM, questo sarebbe legale -- e Waze sarebbe persino obbligato di mettere i dati degli utenti a disposizione sotto la stessa licenza di OSM (CC-BY-SA o ODBL). Però sono quasi sicuro che gli altri fornitori di Waze hanno delle licenze incompatibili sia con CC-BY-SA che con ODBL. Ma... forse si può prendere qualche inspirazione per quanto riguarda la raccolta automatica di dati... Volker Schmidt wrote: Utilizzano anche dati di altri fornitori, ma non attualmente da OSM. Non ho capito perché ma parlano di aspettare il cambiamento della licenza OSM per poterli utilizzare. Sembra un progetto molto interessante e per certi versi parallelo a OSM negli aspetti di generazione e modifica della mappa. 2011/12/15 sabas88 saba...@gmail.com mailto:saba...@gmail.com Ho visto oggi questo servizio. http://it.waze.com/ Sembra una mappatura generata grazie al gps degli utenti. Qualcuno ne sa qualcosa? Compatibilità con OSM? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Edifici Adiacenti
frankieorabona wrote: è propio questo che non ho capito come fare, poichè poichè se faccio come dici la parte in comune non mi viene divisa(esce un triangolo di area) Beh, non so come fai a far comparire un triangolo, però in realtà è semplice... disegna ogni edificio come una way chiusa e appositamente taggata. Per la parte in comune (che, se non capisco male, dovrebbe essere solo un muro e perciò rappresentato come una linea): quando disegni il secondo edificio, riutilizza i node comuni. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Inserire da scontrini
David Paleino wrote: Lista delle correzioni: 1) al numero telefonico, se è preceduto dal codice internazionale, non serve lo 0 iniziale :) -- tant'è che in alcune forme si scrive +39(0)... (quindi o 0..., oppure +39...); In Italia serve, perché dall'estero chiameresti ad es. 0039 02 88620 per raggiungere un numero a Milano. Quindi la forma corretta è +39 02 88620. E' diverso per i numeri cellulari: qui la forma infatti sarebbe +39 333 555 (anche da un telefono fisso si digita 333 555, senza dover anteporre lo zero). La forma +39 (0)... probabilmente risale ai tempi in cui esistevano ancora dei veri prefissi locali, che si potevano omettere per le chiamate nella stessa area e, se non ricordo male, lo zero non si digitava chiamando dall'estero. Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Domande da principiante
Alessandro Chiostri wrote: Bene allora ... Qui fuori c'è un chilometro e mezzo di strada che è stata divisa (male) in due carreggiate con aiuola larga un paio di metri a far da spartitraffico. In dei punti questo si interrompe, e se ciò avviene in corrispondenza di una strada secondaria dalla quale è possibile immettersi sulla principale svoltandi anche a sinistra, allora va da sé che le due carreggiate verranno unite da un pezzerttino di way perpendicolare, ma se lo spartitraffico manca per 30/40 metri ? Si ritorna ad indicare una way singola ? Se la lunghezza di tale tratta è visivamente molto superiore alla larghezza della strada incrociante, io metterei una way singola. Ed in questi casi il passaggio da 1 a 2 way ( da 1 a 2 carreggiate) deve formare visivamente una T oppure una Y ? Meglio una Y. Cosi un navigatore ti direbbe tenere la destra; altrimenti ti potrebbe risultare girare a destra. In realtà tutti e due sono delle imprecisioni, con una T però l'imprecisione diverrebe ancora più grossa. Buona mappatura ancora! Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Ketten - wie taggen?
Martin Koppenhoefer wrote: Am 5. Oktober 2011 18:33 schrieb Gerritz0idb...@gmx.de: ich habe jetzt einige Filialen der Videothekenkette „World of Video“ hinzugefügt, mich dabei aber folgendes gefragt: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). neben operator käme evtl. auch brand in Frage. Im Prinzip ja, allerdings kann ein und derselbe operator mehrere brands betreiben. Beispielsweise führen viele Ketten kleinere Filialen unter eigenen Marken. Beispiel: operator=REWE, brand=REWE city oder brand=REWE Weitere Beispiele fallen mir derzeit nur außerhalb Deutschlands ein: operator=Maxima, brand=Maxima X oder brand=Maxima XX oder brand=Maxima XXX (dort gibt die Zahl der X die Größe des Geschäfts an) operator=Esselunga, name=Esselunga di Via Novara (Esselunga vergibt Orts- oder Straßennamen für seine Filialen) operator=iki, brand=iki oder brand=ikiukas (ikiukas sind kleinere Märkte mit eingeschränktem Angebot) Es hat also jeder der drei Tags operator, brand und name seine Berechtigung und eine eigene Bedeutung. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ketten - wie taggen?
Robert Kaiser wrote: Gerrit schrieb: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). AFAIK ist operator=o korrekt, aber genug Leute taggen für den Renderer, und der stellt es nur dar, wenn es (fälschlicherweise) im name=teht. Robert Kaiser siehe hierzu auch mein früheres Posting (habe Deins erst danach gesehen, sorry). Zum Rendering – am saubersten wäre es wohl, mit COALESCE(name, COALESCE(brand, operator)) zu arbeiten. Dann wird aus den Tags name, brand, operator der erste nicht-leere gerendert. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-transit] commuter rail
On 10/04/2011 03:32 PM, Arun Ganesh wrote: I did not propose to tag the *way* as commuter rail, but the *relations* regarding these train connections. Commuter rail often uses the same rail tracks as long distance services. That is why railway=rail is correct for the ways; but IMHO route=commuter for the relations is interesting information. Ah ofcoure, relation tagging makes sense. +1 Currently, I see that in Germany some systems are tagged as light_rail (those which use dedicated rail infrastructure), others are tagged as train (or rail, not sure) if they use standard rail infrastructure, but both are marketed in the same way (S-Bahn) and passengers likely will perceive both systems as being similar. And as the wiki page [1] states: it's generally best to go with whatever the users of that service general understanding of it would be -- so having two different tags for route relations which users perceive as similar is not really nice. Yes, a dedicated route type for this would be very much appreciated. You might want to add some characteristics that generally distinguish such services from ordinary rail connections: - Metropolitan area (city and surroundings) - Schedules with frequent runs at mostly constant intervals (such as every 20 minutes) - Relatively short distance between stops (shorter than ordinary rail services) - Often special rolling stock, optimized for acceleration and quick boarding - Services are commonly identified by a single ref which is applied to all runs of that service (similar to tram/subway networks) - Often integrated into urban fare system (same ticket as for buses, trams, subway etc.) [1] http://wiki.openstreetmap.org/wiki/Public_Transport Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping public transport network in Port au Prince
On 09/01/2011 07:03 AM, Sébastien Pierrel wrote: Hello list, I'm getting the local mappers of Haiti to map the taptap routes in Port au Prince. Has anyone already mapped the transit network of a similar country? There's a brief mention of shared taxis in the wiki http://wiki.openstreetmap.org/wiki/Shared_transport but not very helpful. We're considering to tag relations with the following tags: type=route route=bus bus=share_taxi name=* (example http://www.openstreetmap.org/browse/relation/1734930) Hi Sébastien, You might want to have a look at route=share_taxi [1]. I have seen this being used in Russia. It's rendered on the latlon.org public transport layer; also openmap.lt used to have it (I'll ask the author what happened to it). Michael [1] http://wiki.openstreetmap.org/wiki/Tag:route%3Dshare_taxi ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-de] Hinweis zum Mappen in Frankreich
Henning Scholland wrote: Am 24.08.2011 16:55, schrieb Chris66: Am 24.08.2011 16:33, schrieb Rainer Kluge: - Landuse ist in F überwiegend durch automatischen CORINE-Import erzeugt und weicht daher oft erheblich von der Realität ab. Wieso daher ? ;-) Weil CORINE, soweit ich weiß, per Satellit erfasst wird und damit die Auflösung begrenzt ist; auch kann bei der automatisierten Auswertung der Bilddaten auch mal der eine oder andere Fehler passieren. Mit GPS-Traces oder guten Luftbildern, die man dann von Hand abzeichnet, bekommt man bessere Ergebnisse. Ich habe mal einen Fall in Savoyen korrigiert, wo ein Stausee laut CORINE auch gleich die Straßen entlang der Ufer geflutet hat. Lage und Landuse waren zwar prinzipiell korrekt, aber die Kontur war sehr grob und die Fläche des Objekts war geschätzt doppelt so groß wie in Wirklichkeit. Wenn die Corine Daten so schlecht sind, wieso werden sie dann importiert ? ...weil eine bunte volle Karte schöner aussieht als eine weiße leere ;) Oder weil man mit deutlich weniger Aufwand eine einigermaßen passabel aussehende Karte bekommt – zumindest für bestimmte Objekte. Für niedrige Zoomstufen und zur groben Orientierung reicht die Präzision von CORINE ja. Aber da gehen die Meinungen auseinander: Als vor ein paar Monaten die Ergebnisse des CORINE-Imports in Rumänien Image of the Week waren, gab es bei uns in Italien auch die Diskussion, ob wir nachziehen sollten. Die Mehrheit war dagegen (nur Südtirol hat Daten importiert); das Ergebnis ist, dass in Italien deutlich weniger landuses gemappt sind als in Frankreich. Auch wird angeführt, dass Importe beim Aufbau einer Community eher hinderlich sind – auch hierfür gibt es in Frankreich einige Beispiele, wo Ortschaften zwar mit allen landcovers und Häusern erfasst sind, aber keine einzige Straße eingezeichnet ist... Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Android
Dimitri Junker wrote: Hallo, Nach vielem testen, googeln,... ist der Stand jetzt der: es gibt kein Navit.xml, man kann dies aber aus den apk extrahieren, da gibt es 3 je nach Bildschirmauflösung. Wenn ich dort den Pfad ändere und es nach sdcard/navit kopiere wird dies bei Download ignoriert. Aber zur Anzeige der Karte wird es wohl ausgewertet, aber so, daß bei mir keine Karte mehr angezeigt wird. Hmmm... versuche mal, irgendeinen Parameter in der navit.xml testweise zu ändern (z.B. ein OSD-Element deaktivieren) und schau, ob das in navit ausgewertet wird. Wenn ja, dann liegt zumindest schon mal die navit.xml an der richtigen Stelle. Wie der Download von Kartendaten direkt mit Navit funktioniert, habe ich noch nicht probiert... ich nutze den Navit Planet Extractor. Dort ein Recheck auswählen (testweise tut's ein kleines rund ums eigene Haus) und als navitmap.bin auf der SD-Karte abspeichern (im Navit-Verzeichnis, wo auch die xml-Datei liegt). Jetzt gilt es nur noch, den Pfad herauszufinden: Dazu brauchst Du einen Filemanager oder eine Kommandozeile auf dem Handy, per adb verbinden geht auch. Dann durch die Verzeichnistruktur hangeln, um den vollen Pfad zur bin-Datei herauszufinden. Bei mir ist das zum Beispiel /sdacrd/navit/navitmap.bin. Den Pfad dann in der XML-Datei entsprechend eintragen, das sollte ungefähr so aussehen: mapset map type=binfile enabled=yes data=/sdcard/navit/navitmap.bin / /mapset Vorsicht mit relativen Pfaden – keine Ahnung, zu was die relativ sind... zum Verzeichnis, in dem die navit.xml liegt, oder zu dem, in dem die Binaries liegen oder weiß der Himmel was... Hope it helps... und nicht verzagen, Navit hat zwar noch seine Ecken, aber in Sachen Entwicklung tut sich vieles, und was heute noch nicht funktioniert, kann schon bald besser werden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Android
Michael Zimmermann wrote: On Mon, 15 Aug 2011 02:04:14 +0200 Dimitri Junkero...@dimitri-junker.de wrote: Das erhöht den Aufwand für die Portierbarkeit auf andere Systeme... Wieso? Was meinst Du mit anderes System? Dieser fixe Pfad ist ja wohl ser Systemspeziefisch, also wäre eine Pfadauswahl doch wohl Systemunabhängiger. Und wenn da wirklich ein Programmierer Probleme hat eine Pfadauswahl einzubauen dann könnte man ja ein einfaches Konfigurationsfile nutzen. So ist es unbrauchbar! Die Karten samt Pfaden sind in der navit.xml hinterlegt, und die unterscheidet sich ohnehin schon von Plattform zu Plattform. Auf Windows CE ist beispielsweise ein Kartenausschnitt von München im Paket enthalten und konfiguriert... Hi, dann suche mal nach navit.xml (configfile) darin dann nach maps und passe dir den Pfad an hab aber keine Ahnung wo das auf einem Android liegt Im APK-File; soweit ich weiß, wird das irgendwohin extrahiert und dann diese Kopie benutzt (würde auf /data tippen). Ansonsten gibt es die Möglichkeit, eine eigene navit.xml auf der SD-Karte abzulegen, die dann Vorrang hat. Die muss auf der SD-Karte unter /navit/navit.xml liegen. In der kannst Du dann jeden beliebigen Pfad für die Kartendaten konfigurieren. Haken an der Sache: ob das mit der navit.xml auch funktioniert, wenn die SD-Karte nicht als /sdcard gemounted ist, weiß ich nicht... Im navit-Bugtracker sind zwei Tickets offen, um Navit auf SD installieren zu können [1] [2] und so auch ohne Rooting an die Konfigurationsdateien zu kommen. Wenn das alles nichts hilft, bleibt Dur nichts anderes, als noch ein Ticket aufzumachen und auf die Problematik hinzuweisen. Evtl. kann man ja, anstatt den Pfad /sdcard hart zu codieren, den tatsächlichen Pfad aus der Systemkonfiguration auslesen (z.B. aus der mtab). Irgendwie müssen ja auch andere Android-Apps mitbekommen, welchen Pfad die SD bzw. der integrierte Speicher hat, also muss das irgendwo hinterlegt sein... Michael [1] http://trac.navit-project.org/ticket/818 [2] http://trac.navit-project.org/ticket/918 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + alley?
Falk Zscheile wrote: Am 20. August 2011 10:41 schrieb yzemazeyzem...@gmx.net: On 20.08.2011 09:33, Peter wrote: Hi Gestern traf ich auf ein Eckchen wo recht viele kleine Zufahrtssträßchen liegen, Neubaugebiet. Ich würde denen gerne ein service=alley verpassen da das trifft, viel kleiner als normale Straßen. Die meisten Straßen dort sind auch normalbreit für eine Wohngegend. Nun ist das zum Teil aber auch verkehrsberuhigt, Spielstraße. Da beißt sich das da highway=living_street|service) sich ausschließt. Falsches Taggingschema? living_street hat IMHO mehr was richtung maxspeed. Naja. Also: highway=service , service=alley oder highway=living_street Im Moment taggte ich letzteres. Die schmalheit der Wege liesse sich mit width markieren, aber so genau wollte ich es auch nicht unbedingt, die klasse alley täte es eher. Weis einer ein passendes tagging ohne ein Faß von proposal aufzumachen? Moin, living_street=yes + traffic_sign=DE:325 ergänzen In Bamberg gibt es etliche ähnlich gelagerte Fälle, d. h. enge Gassen als verkehrsberuhigter Bereich (DE:325) ausgewiesen. Der hiesige Powermapper theophrastos hat die - vermutlich in Ermangelung eines besseren Schemas - samt und sonders als highway=service, service=alley, living_street=yes getaggt und noch eine note drangehängt, dass das so Absicht ist. Da mir bis dato auch nix besseres eingefallen ist (und ich auch ungern edit-wars starte ;)), habe ich erstmal die Finger davon gelassen, mal davon ausgehend, dass beispielsweise Routing-Anwendungen service und living_street ähnlich gewichten. Bei genauerer Überlegung sollte man sicherlich traffic_sign=DE:325 ergänzen. Die wiki-konforme (mir eher zusagende) Alternative hast du ja schon genannt. Was spräche gegen die Variante highway=living_street, living_street=alley um zu zeigen, dass der Weg kleiner als normalerweise ist? Natürlich ist auch das nicht wiki-konform und bisher wohl nicht praktiziert ... highway=living_street ist genau für Straßen gedacht, die als Spielstraße/verkehrsberuhigter Bereich, home zone etc. (je nach Land) markiert sind. Über die Breite sagt das an sich noch nichts aus. Siehe hierzu auch das Wiki [1]. highway=service ist eher für Einfahrten bzw. Zufahrten gedacht, etwa zu Parkplätzen, Tankstellen oder Grundstückseinfahrten. Das sagt auch nicht unbedingt was über die Größe aus; die Zufahrten zu Autobahnparkplätzen können ziemlich großzügig sein. [2] Meine Faustregel: wenn die Gemeinde Straßennamen verwendet und die Straße einen Namen hat, ist es kein service mehr. Für die beschriebenen Fälle: steht an der fraglichen Straße selbst das entsprechende Schild Spielstraße? Wenn ja, dann würde ich sagen: highway=living_street. Die Breite würde ich in der Tat in einem Zusatztag unterbringen, falls nötig. living_street=alley wäre von daher OK, ggf. könnte man das ja als Proposal einreichen. Wenn das allerdings Einfahrten sind, die nur zu je einem Grundstück führen (maximal zwei), selbst keine Straßennamen haben und selbst nicht als Spielstraße markiert sind (sondern z.B. von einer entsprechend markierten Straße abzweigen), dann würde ich highway=service vergeben. Nationale Tags wie traffic_sign=DE:325 würde ich so weit wie möglich meiden... wenn das auch woanders auf der Welt so gehandhabt wird, wird die Auswertung solcher Tags ein Alptraum, wenn sie denn auch grenzübergreifend funktionieren soll. In der Praxis werden solche Tags dann wohl weitgehend ignoriert, der Zusatznutzen geht also gegen Null. Aus dem gleichen Grund verwenden wir ja auch in Deutschland nicht highway=bundesstrasse, sondern highway=primary und dergleichen. [1] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street [2] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] bug mapnik?
Fabri wrote: Ho inserito in osm degli higway=service che attraversano un edifico (building=yes) ma la strada di servizio viene renderizzata sopra l'edificio; ho provato varie combinazioni, giocando con i layer, e anche con tunnel=yes ma niente. invece su osmarender viene renderizzata correttamente con il layer dell'edificio sopra la strada. avete riscontrato anche voi questa stranezza? Confermo, neanche la combinazione covered=yes; layer=-1 viene renderizzata correttamente. stesso problema anche con service=parking_aisle. che si fa? si apre un ticket sul trac di mapnik? Dovrebbe già esserci. Il problema è che mapnik nella versione presente no conosce nessun'ordine nella dimensione z, invece gli oggetti vengono messi a secondo dell'ordine in cui sono definiti i relativi layer. Con quel sistema diventa difficile indicare cosa dovrebbe essere sopra o sotto. Per i highway è stato fatto, per gli altri oggetti invece no. Per le versioni future di mapnik mi sa che stiano già lavorando su una propria e vera z-order, mecanismo con cui verrebbe risolto anche questo problema. Però... forse esiste un workaround: dato che per i highway ciascun layer=* ha il suo proprio layer in mapnik, magari conviene spostare le definizioni per i layer sotto zero più in alto (prima delle regole per building, ma dopo quelle per landuse e simili). ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Wasd arf alles für OSM verwendet werden ?
Steffen Heinz wrote: gibt es irgendwo ne Stelle wo geschrieben steht was alles für OSM verwendet werden darf (wenn nicht wäre das sinnvoll) http://wiki.openstreetmap.org/wiki/Potential_Datasources Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Letture Perché i dati geografici non possono essere liberi
Simone Cortesi wrote: 2011/7/11 Maurizio Napolitanonapoo...@gmail.com: Mi hanno girato questo articolo http://www.rivistageomedia.it/201107103458/Approfondimenti/perche-i-dati-geografici-non-possono-essere-liberi-se-vogliono-essere-onesti.html secondo me questo ha paura ... Puro FUD: Fear Uncertainty Disaster Mi sembrano frasi e paragrafi sconnessi fra di loro. Fra cui il capolavoro finale: Un ultima considerazione: al di la di quello che può essere la sperimentazione o il diletto, affidereste mai la vostra navigazione ai dati “liberi” ? L’affidabilità completa sulla navigazione stradale oggi non l’abbiamo neanche dai dati Teleatlas, notoriamente costosi. E voi affidereste gli spostamenti delle vostre merci a sistemi così poco affidabili? Provate pure, usate un navigatore con dati liberi e fatemi sapere. Dieci o quindici anni fa la gente diceva le stesse cose sull'uso dell'Internet per lo scambio di dati critici nel contesto aziendale. L'argomento principale: nella rete non è garantito né quando il messaggio arriva dal destinatario, né se arriva o meno, affidabilità insufficiente per un qualsiasi uso aziendale. E oggi? Quante aziende pagano ancora per una linea dedicata? Il cosiddetto impossibile è ormai diventato realtà... Per quanto riguarda l'accuratezza/completezza delle mappe e l'usabilità: concordo che la technologia deve ancora maturare, ma la stessa cosa si può/poteva dire anche dell'internet... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] OSM kompatible Navi
Sven Geggus wrote: Henning Schollando...@aighes.de wrote: Die Hardware gibt es schon. Software ist auch reichlich verfügbar. Das gesuchte Gerät wäre Defy in einem Garmin-Gehäuse oder ein Garmin mit Android. Gibt es eigentlich Infos dazu welche Hardware in den Outdoorgeräten von Garmin drinsteckt und ob man da prinzipiell Linux drauf portieren könnte? Einige Nüvi basieren AFAIR ohnehin auf Linux. Aufwand diese seitens Garmin alternativ auch mit offenen OS anzubieten etwa eine Mannwoche oder so. Bei Garmin bin ich mir nicht sicher, aber Tomtom setzt (zumindest für einige Geräte) Linux ein. Gerätespezifische Sourcen bietet Tomtom zum Download an (wohl auf Grund von Verpflichtungen durch die GPL); es gibt schon ein Projekt [1], das sich mit weiteren Möglichkeiten auf der Plattform befasst. Ansonsten fällt mir der Openmoko Freerunner [2] oder dessen (noch in Entwicklung befindliche) Nachfolger GTA04 [3] ein. Der Freerunner war ein guter Ansatz, gefallen hat mir das (vor allem für ein Smartphone) recht präzise GPS – Referenzgeräte sind mein Mio 168 RS, Bj. 2005, und mein Geeksphone One, Bj. 2010; der Mio wird leicht, das Geeksphone sogar bei weitem übertroffen. Auch das Display mit 480x640 Pixel (knapp unter 300 ppi) war ein guter Ansatz. Negativpunkte waren: langsamer Grafikchip und der ARMv4-Prozessor. Die Openmoko-Distros haben mich nicht überzeugt, und Android kam erst später – die Hardware war dafür nie gedacht (Android ist für ARMv5 entwickelt). Daher läuft Android auf dem Freerunner nur sehr zäh. Der Nachfolger – wenn er denn kommt – könnte besser werden. Einschränkung bei dem Ganzen: outdoorfähig habe ich nichts von alle dem gesehen. Klar, bei Schönwetter funktioniert's, und den Freerunner habe ich auch schon bei Schneetreiben etliche Stunden im Stirnband meiner Skibrille spazieren gefahren, aber dafür ausgelegt ist er nicht wirklich... [1] http://opentom.org/Main_Page [2] http://www.openmoko.org [3] http://www.gta04.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Help-Installazione Josm in Ubuntu
Orlandi_IT_EmiliaRomagna wrote: sudo wget http://josm.openstreetmap.de/josm-latest.jar -O /usr/share/josm/josm.jar Grazie mille!!! Era proprio questo che cercavo ricordati solo di fare chmod a+x (per poter eseguire il jar deve essere eseguibile, se lo scarico con Firefox non lo è). Questo vale anche se aggiorni JOSM (l'attributo si risetta se sostituisci il file). ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Luftbilder für JOSM
Frederik Ramm wrote: Da verkennst Du die Lage glaub ich ein bisschen. Diese Yahoo-Geschichte war noch nie was wirklich offizielles. Anders als Bing hat Yahoo nie irgendwas oeffentlich gesagt a la wir finden OSM toll und unterstuetzen die mit unseren Luftbildern. Yahoo hat lediglich auf Anfrage hin auf halb-privaten Kanaelen (ein OSMF-Vorstandsmitglied war frueher mal bei Yahoo) erklaert, dass sie nichts dagegen haben, wenn wir ihre Bilder abmalen. Trotz vieler Nachfragen haben wir das nie schwarz auf weiss bekommen, und vermutlich arbeitet inzwischen niemand von denen, mit denen wir damals geredet haben, mehr da. Wenn ich die Infos im Wiki richtig verstehe, dann war die Aussage von Yahoo seinerzeit eine derartige Nutzung ist mit unseren Lizenzbestimmungen kompatibel. Damit wäre ein gesondertes Agreement nicht erforderlich und im Prinzip könnten auch andere die Yahoo-Luftbilder für ihre Zwecke abmalen. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] ferrovie milano
Lo avevo contattato per garantire la coesistenza con le relazioni dei trasporti pubblici. Per quanto ne sappia ha usato le ortofoto (PCN e Bing). In una zona al sud-est mi ha detto che si è fermato per il momento, causa modifiche ai binari dopo la data in cui sono state scattate le ortofoto. Ruggero wrote: Ho notato che il dettaglio delle ferrovie di Milano è notevolemente migliorato: http://www.openstreetmap.org/?latE.49183lon=9.21478zoomlayers=M http://www.openstreetmap.org/?latE.47707lon=9.27611zoomlayers=M gli edit sono stati fatti da averageman dubito che la PCN sia sufficiente per ottenere un risultato simile, mi chiedevo da dove fossero stati presi i dati. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-de] Wie Kartenbereich aus API-Export rendern
Hallo, sorry, dass ich mich erst jetzt einklinke. Wie man im Prinzip aus einem OSM-File (z.B. einem API-Export) mit Mapnik eine Karte rendert, ist im Wiki unter [1] dokumentiert. Prinzipiell ist es auch möglich, den OSM-Style so umzubiegen, dass Mapnik die Karte aus einem OSM-File statt aus PostgreSQL rendert. Das ist zwar mit einigen Einschränkungen verbunden, aber das Ergebnis dürfte der Karte von der OSM-Homepage recht nahe kommen. Zuerst wirst Du die ganzen Layers im Style durchgehen müssen: - Datasource anschauen: welche Tags werden gefiltert? - Datasource so umbauen, dass die Daten aus dem XML-File geholt werden - Alle Styles, die von dem jeweiligen Layers referenziert werden, anpassen: da die Filterregeln jetzt auf ALLE Objekte angewandt werden, müssen ggf. zuvor in der Datasource vorhandene Filterkriterien in die Filters der jeweiligen Rules wandern. - Achtung: falls ein Style von mehr als einem Layer referenziert wird (die dann höchstwahrscheinlich unterschiedliche Datasources haben und die Daten unterschiedlich filtern), wirst Du Diese Styles wahrscheinlich duplizieren müssen, weil Du jetzt für jedes Layer andere Filterregeln brauchst. Einschränkungen: Einige Features im Default-Style benutzen PostGIS-Funktionen: Beispielsweise werden turning_circles mit der Farbe gefüllt, die zur nächstliegenden Straße passt. Diese Features hast Du mit einem OSM-Datasource nicht zur Verfügung; hier ist Kreativität gefragt. (Beispielsweise nur die casings, sprich den grauen Rand, zu rendern und die Füllfarbe wegzulassen.) Ebenso wirst Du darauf verzichten müssen, Renderingregeln für Polygone erst ab einer bestimmten Fläche greifen zu lassen. Relationen werden von Mapnik überhaupt nicht unterstützt. Informationen, die in Relationen enthalten sind, können nicht gerendert werden. Speziell fällt mir dazu multipolygon ein – Gebäude mit Innenhöfen, Wälder mit Lichtungen usw. können so nicht wie auf der OSM-Homepage dargestellt werden. Es gibt keine Unterscheidung zwischen Nodes und Ways. Areas können halbwegs erraten werden, indem nach eindeutigen Tags gefiltert wird (area, building, landuse etc.), allerdings werden auf diese Weise auch Nodes als Areas behandelt, wenn sie eines dieser Tags besitzen. Außerdem scheint es noch ein paar Bugs zu geben – ich habe mal kleinere Bereiche ad-hoc auf diese Art gerendert, und in einzelnen Fällen musste ich feststellen, dass die Geometrie von Objekt A und Tags von Objekt B durcheinandergewürfelt wurden. Ich erinnere mich an einen Fall, in dem die Umrisse eines Gebäudes hartnäckig und reproduzierbar als Skipiste gerendert wurden... die Skipiste gab es tatsächlich, nur woanders... Um die Karte als Bitmap zu rendern, gibt es, wie schon vorher angesprochen, nik2img.py. Eine Alternative dazu könnte auch der Mapnik Viewer sein: den Code gibt es auf der Mapnik-Homepage zum Download; Binaries werden vom Projekt nicht angeboten. (Ubuntu bietet allerdings ein Package mapnik-viewer an.) Mit dem Viewer kannst Du Dir den gewünschten Kartenausschnitt auf dem Bildschirm heranholen und dann über die Export-Funktion in ein Bitmap exportieren. Einschränkung: es wird genau das exportiert, was Du auf dem Bildschirm siehst – gleicher Ausschnitt, gleicher Zoom. Wenn Du einen kleineren Ausschnitt brauchst, entweder Fenster vor dem Export verkleinern oder Bitmap hinterher zurechtschneiden. Der maximal exportierbare Kartenausschnitt ist etwas kleiner als Deine Bildschirmauflösung... Hope it helps Michael [1] http://wiki.openstreetmap.org/wiki/Mapnik:_Rendering_OSM_XML_data_directly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Performance-Steigerung durch Proxy-Server
Hallo, openmap.lt fährt eine Proxy-Konfiguration – Betreiber ist Ramas [User:Ieskok]. Im Detail kenne ich seine Konfiguration zwar nicht, Kern scheint aber ein Apache-Server mit Squid als Reverse Proxy zu sein. Ob das die Performance verbessert, hängt von ein paar Faktoren ab: Zum einen ist ein Performancegewinn erst dann möglich, wenn eine Anfrage aus dem Cache bedient werden kann – also frühestens ab der zweiten Anfrage pro Kachel. Das hängt also sehr davon ab, wie viel Traffic der Proxy bekommt und wie sich dieser auf die Tilesets verteilt. Je weniger Streuung, um so besser. Zum anderen bringt es auch nur dann etwas, wenn der Proxy die Anfragen schneller bedienen kann als der OSM-Server selbst – zum Beispiel wegen besserer Netzverbindung oder geringerer Auslastung von Server-Ressourcen (einschließlich Netzverbindung). Spontan fallen mir da Firmennetzwerke und dergleichen ein, wenn diese nur eine schmale und/oder stark ausgelastete Verbindung zur Außenwelt haben. Neben der Performance ist ein weiterer Bonus die Ausfallsicherheit: sollten die OSM-Server nicht erreichbar sein, hat der Proxy immer noch Daten im Cache. Wenn also viele User vorrangig die gleichen Gebiete anschauen, kann ein solcher Ausfall recht gut überbrückt werden. Zwei Probleme stellen sich: zunächst die Aktualität der Tiles. Idealerweise holt der Proxy die Kacheln nur dann neu vom Server, wenn sich dort etwas geändert hat, und beantwortet sonst alle Anfragen aus dem Cache. Möglich wäre hier eine Staffelung: wenn eine Kachel weniger als x Sekunden/Minuten alt ist, wird sie ohne Wenn und Aber aus dem Cache geliefert, ansonsten wird mit einem HEAD-Request an den OSM-Server überprüft, ob es dort eine neuere Version gibt – wenn ja, wird diese vom Server geholt, ansonsten wird der Request ebenfalls aus dem Cache beantwortet. Im schlimmsten Fall werden dann halt mal Kacheln zurückgeliefert, die seit maximal x Sekunden/Minuten veraltet sind. Auf openmap.lt sehe ich zwar öfter mal veraltete Kacheln in Bereichen, die ich kurz zuvor editiert habe, allerdings hilft da meist ein Refresh der betreffenden Kachel (auch bei sehr frischen Updates), kann also auch an meinem lokalen Browsercache liegen. Zum anderen, wie bereits erwähnt, die Tile Usage Policy: ein Proxy mit entsprechend Traffic kann hier schnell mal an die Grenzwerte stoßen und geblockt werden. Andererseits entlastet ein Proxy ja gerade die OSM-Server, so dass eine derartige Konfiguration durchaus im Sinne der Policy sein sollte – diese hat ja schließlich das Ziel, die Serverresourcen vor Überlastung zu schützen. Wenn jemand so etwas plant, würde ich empfehlen, einfach mal die Server-Admins anzuschreiben, denen das Vorhaben zu erklären – wenn das sauber gemacht wird, sollte es eigentlich im Sinne von OSM sein. my 2 cents Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Haltestellen-Namen
Hallo zusammen, Hallo Steffen, hallo @talk-de, / da nebenan eine heftige Diskussion um Namenszusätze im Gange ist, // wurde ich an ein Problem erinnert, dem ich vor einigen Tagen gegen- // überstand: Haltestellennamen für Bushaltestellen von Überlandlinien. // Auf den Haltestellentafeln in der Stadt steht (natürlich) nicht der // Name der Stadt (also Lindengarten und nicht Wismar Lindengarten, // Ausnahme Wismar ZOB). Außerhalb der Stadtgrenzen heißt es dann schon // Groß Strömkendorf Dorf oder Hof Redentin Abzweig. // In den Online-Fahrplänen steht (natürlich?) Wismar Lindengarten, // wenigstens nicht Hansestadt Wismar Lindengarten, denn das könnten die // wenigsten Schriftanzeiger in den Bussen auch darstellen. // Wie verfährt man in diesem Fall am saubersten? /das ist in der Tat ein ziemlich hartnäckiges Problem, auch außerhalb von OSM. In Vorarlberg habe ich etliche Haltestellen gesehen, die wohl aus einem Import stammen und z.B. mit name=Feldkirch, Zollamt getaggt sind. In Italien stoße ich öfter auf name=Via Dante (Cormano) - beides gefällt mir allerdings nicht sonderlich. Das Problem ließe sich recht einfach und elegant durch einen Zusatztag lösen. Beispielsweise is_in, oder ein anderer (noch zu benennender) Tag. Im obigen Beispiel wäre das dann: name=Lindengarten is_in=Wismar Dann kann sich jeder Renderer daraus den für sich passenden Namen zusammenbauen. Für eine topographische Karte kann man is_in getrost ignorieren (in welcher Stadt die Haltestelle ist, sieht man dort meist deutlich). Für Liniendiagramme und dergl. kann man is_in auswerten und z.B. nur für die Linien rendern, die Haltestellen mit unterschiedlichen is_in-Tags bedienen. Die Art der Darstellung bleibt dem Renderer überlassen: Wismar, Lindengarten oder Lindengarten (Wismar) oder WISMAR Lindengarten A-Straße B-Straße GROSS STRÖMKENDORF Dorf usw. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] ritorno della ÖPNV
M∡rtin Koppenhoefer wrote: segnalo a tutti che la http://www.öpnvkarte.de/ è ritornato - giusto nel caso che vi sono mancati gli Umlaute nell'adress-bar ;-) Al momento i dati sono del 11.5.2011 ulteriori informazioni del mondo trasporti: openmap.lt ormai renderizza anche tram, metrò, light_rail, train, share_taxi e ferry ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Stazioni ferroviarie
Luciano Montanaro wrote: 2011/5/21 toterag...@hotmail.it: - Il tag name. In molte stazioni è utilizzato semplicemente il nome della stazione (name=ovarolo), in alcune una cosa del tipo name=Stazione di Piovarolo. Io in alcune occasioni ho cancellato la parte Stazione di , ma è stata una decisione arbitraria, anche qui sarebbe opportuno che la comunità si accordasse. Ah, sì, l'avevo dimenticato nel messaggio precedente, ma anche a me creerebbe problemi. Sarebbe meglio usare il nome ufficiale della stazione (quello riconosciuto dai siti di ricerca di trenitalia) e basta. O tutti con lo stesso prefisso (Stazione di... o Fermata di..., se vogliamo fare una distinzione). Per favore... nel tag name va messo solo il nome della stazione. Non serve mettere stazione di... o fermata di..., questo lo sappiamo già del tag railway=station/halt. Lo stesso vale per l'operatore (FNM, FS etc.) - questo va messo nel tag operator=*, non nel nome. Altrimenti ogni elenco alfabetico, ricerca per none etc. diverrebbe un casino. Unica eccezione: se in un posto dovessero essere due stazioni di due operatori con nessun'altra distinzione nel nome, conviene mettere l'operatore *dopo* il nome (Posto FS, Posto FNM). Chiunque dovesse aver bisogno di renderizzare il nome col prefisso o un operatore può configurare appositamente il renderizzatore o aggiustarsi i dati sul suo sistema. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Dutch Transit data release
Hi Andre, For the licensing part, you might want to get in contact with Henk Hoff [1] (in cc). He is based in the Netherlands and a member of the OSM Foundation Board and of the License Working Group, thus he should be able to speak with an official voice. As for the technical aspects: to my knowledge, there is no formal transit group; de facto, this list is the main exchange for such topics. Maybe some of the Dutch members on this list can take over. There is also a Dutch mailing list [2], not specifically related to public transport but may reach a larger number of Dutch users. Henk may also be able to provide a pointer. Good luck with your project - I am happy to see official public transport data being opened up to OSM. Michael [1] http://wiki.openstreetmap.org/wiki/User:Toffehoff [2] http://lists.openstreetmap.org/listinfo/talk-nl On 05/12/2011 04:57 PM, andre van atten wrote: As an employee of the dutch 9292 company I can inform you that we like to contact a Dutch leading member of the transit group in the OpenStreetmap community to discuss our intentions to enable the delivery of transit data within the complete boundary of the Netherlands. This will take place under a license within openData terms. We would like to discuss the license form and other delivery requirements. The purpose is to enable the content of public transit data as stops, stations, lines and directions that are available on stops / stations, and line schema. So that this data can be used to construct proper linetopology as it is used in openbusmap.org http://openbusmap.org and other OSM related products as OsmAnd. The data will be refreshed on a regular base to ensure its validity. Please respond with contact name, email and role within transit group and OpenStreetmap group. We will then send an invitation to discuss issues in person on our location in Utrecht. Best Regards A van Atten ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Mappa trasporti pubblici
On 04/27/2011 06:36 PM, Michael von Glasow wrote: totera wrote: Grazie della segnalazione! Hai anche avuto modo di renderti conto della frequenza di aggiornamento? il weekend ho aggiunto una linea nuova, che fino ad oggi non è comparsa... perciò direi che probabilmente ci mette un paio di giorni. ho appena sentito Ramūnas (l'autore), i dati vengono aggiornati almeno una volta per settimana, a volte anche più spesso, soprattutto quando vi sono dei aggiornamenti allo style. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappa trasporti pubblici
totera wrote: Maurizio Daniele wrote: Visto che gli strumenti relativi alle mappe trasporto pubblico (opvnkarte, openstreetbrowser, osmtransport...) hanno grossi problemi di aggiornamento, volevo segnalare la mappa a http://openmap.lt che prevede un layer di trasporto pubblico aggiornato. Grazie della segnalazione! Hai anche avuto modo di renderti conto della frequenza di aggiornamento? il weekend ho aggiunto una linea nuova, che fino ad oggi non è comparsa... perciò direi che probabilmente ci mette un paio di giorni. L'unico problema è che riporta esclusivamente bus e filobus, niente ferrovie, metro e tram. Ho notato che mancano le linee bus prive di ref, mentre compaiono alcune ferrovie (intorno a Roma e in Veneto) dotate di ref. Mancano però la metro di Roma e il tram di Padova, che pure hanno il ref... sì, la mappa è nata in Lituania, dove anche nelle città più grandi (Vilnius e Kaunas) non ci sono né metropolitane (a Vilnius si ne parla, ma il futuro del progetto mi sembra ancora incerto), né tram - la rete è composta di bus, filobus e treni. Però... per quanto ne abbia capito delle conversazioni in talk-lt, openmap.lt è un lavoro cominciato da poco e ancora in corso - circa due settimane fa la copertura dei transporti pubblici era limitata a Lituania, poi è stata estesa al resto di Europa solo ai livelli di zoom bassi, ormai a tutti i livelli. Qualcuno ha già chiesto di aggiungere anche gli altri mezzi, vediamo... ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappatura corsia ciclabile + corsia bus + strada
emmexx wrote: Il 21/04/2011 20:10, Federico Cozzi scrisse: In caso si decidesse di mantenere una way sola, essa dovrebbe giustamente essere mappata: oneway=yes (per indicare il senso unico del flusso principale) cycleway=lane (per indicare la corsia ciclabile, nello stesso verso del flusso principale) A cui aggiungere il tag di accesso psv:backward=yes (per indicare che i mezzi pubblici possono andare in verso opposto) Con questo schema la corsia ciclabile verrebbe correttamente evidenziata sulla OpenCycleMap, e il fatto che la way sia mappata come oneway=yes farebbe apparire la freccia di senso unico (che dopotutto è il verso principale di percorrenza). Direi quindi che il mondo in cui ho proceduto e' coerente con questo schema. Alcuni pezzi della cerchia dei Bastioni (mi scusino i non milanesi) non avevano tutti i tag per la corsia preferenziale e li ho quindi aggiunti. In uno o due casi simili (mi ricordo di uno nelle vicinanze del Cimitero Maggiore) ho anch'io proceduto nello stesso modo, a parte della corsia ciclabile (che nel mio caso non c'era). A proposito della corsia ciclabile: sulla foto non la vedo, vale il senso unico anche per le bici? Se sì, va bene, altrimenti bisognerebbe aggiungere anche bicycle:backward=yes. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] pubblicità guerriglia per Openstreetmap
M∡rtin Koppenhoefer wrote: 2011/4/18 Daniele Forsidfo...@gmail.com: Il 18 aprile 2011 12:21, Fabio Alessandro Locati ha scritto: Prepariamo un documento così poi basta aggiungere la data e stamparlo? sei sicuro che si possa attaccare? non è un'affissione illegale? lo è sicuramente, quindi non mettete il vostro numero di telefono... tanto il numero di telefono non serve, se (come nella foto) è indicata l'ora in cui è avvenuto l'aggiornamento in OSM, della quale si può con poca fatica risalire al changeset e perciò al utente che ha aggiornato i dati ed è il primo candidato per quanto riguarda un'eventuale affissione illegale in merito... Una bella idea, ma bisognerebbe trovare qualche modo legale per fare tale pubblicita - a parte di poter garantire la copertura sufficiente e l'aggiornamento tempestivo della zona interessata. Se no, l'utente che cambia a OSM tornerà alla soluzione commerciale tra poco (vuol dire: dopo il prossimo blocco NON segnalato), dopodiché sarà difficile convincerlo di nuovo di noi... Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Non mi funziona il PCN
M∡rtin Koppenhoefer wrote: 2011/4/11 Niccolo Rigaccio...@rigacci.org: Per quanto riguarda il PCN una cosa che il resto del mondo se la sogne ancora (a precindere delle USA e Canada). ormai anche altri parti dall'Europa offrono dei servizi simili: Spagna ha un servizio paragonabile (50 cm/px), dall'anno scorso anche Austria (70-80 cm/px) e da poco Baviera (2 m/px). Anche per la Francia è stato annunciato, solo che non mi funziona. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Chiusura x lavori
Per il momento probabilmente va bene, alla lunga però io avevo preparato una proposta per casi come questo: http://wiki.openstreetmap.org/wiki/Proposed_features/temporary ciao Michael Alessandro Frigeri wrote: Ciao Carlo, io in un caso simile ho usato: access: no construction: yes magari c'e' un modo migliore per indicare questa situazione? Alessandro Il 26 marzo 2011 19:10,carlo...@teletu.it ha scritto: Salve, ieri a Mantova mi sono trovato in un parcheggio per camper chiuso per lavori( non si sà quando finiranno). E' il caso di aggiornare la mappa e in che modo ? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Chiusura x lavori
On 03/28/2011 11:42 PM, Federico Cozzi wrote: 2011/3/28 Michael von Glasowmich...@vonglasow.com: Per il momento probabilmente va bene, alla lunga però io avevo preparato una proposta per casi come questo: http://wiki.openstreetmap.org/wiki/Proposed_features/temporary Volevo suggerirti di precisare meglio la semantica di temporary (mi sembra un'ottima idea il tuo tag, ma io sono per natura rompi...) Create another tag named temporary: followed by the name of the tag of which you want to change the value, and set the value as needed Esempio: highway=unclassified bicycle=designated Supponi di aggiungere temporary:access=no Per quanto detto sopra, temporary:access fa l'override di access (che non c'è), quindi la strada sarebbe taggata come se fosse: highway=unclassified access=no bicycle=designated che vuol dire che le bici ci possono andare! Probabilmente NON quello che hai in mente quando aggiungi temporary:access=no. In questo caso, la soluzione sarebbe aggiungere anche temporary:bicycle=no per produrre l'effetto corretto. Quindi ti suggerisco di indicare questo contro-esempio nella pagina della proposta, per far capire che il tag temporary in alcuni casi si comporta diversamente da quanto ci si immagini (soprattutto in presenza del tag access e derivati) PS: *non* sto suggerendo di cambiare il funzionamento proposto del tag temporary, cioè di fare l'override anche di *altri* tag oltre a quelli esplicitamente indicati (sarebbe un delirio per qualsiasi software) Ciao, Federico Sono d'accordo, infatti non avevo pensato bene agli effetti collaterali. Ho aggiunto il tuo esempio e nella sezione How to Interpret and Render ho chiarito che si tratta di una semplice sostituzione dei tag. Se qualcuno ha qualche modo di spiegarlo meglio, sarà il benvenuto... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ponte crollato
On 01/-10/-28163 08:59 PM, Stefano Salvador wrote: highway=nstruction? ricalcando quello che è stato fatto per Haiti forse anche un highway=llapsed. Ciao, Stefano highway=construction lo intenderei come una nuova strada in fase di ultimazione, non per una strada diventata inutilizzabile e in attesa di rinnovo. highway=collapsed mi pare più giusto per un ponte crollato, secondo me è sufficiente in questo specifico caso. Sono però anche da considerare: - le ponti che hanno subito dei danni strutturali e perciò sono chiusi solo per certi tipi di traffico (al traffico motorizzato, limite di peso ecc.) - le strade inutilizzabili perché allagati, senza aver subito dei danni strutturali - le strade che, pur essendo intatti e in teoria accessibili, ormai finiscono nel nulla (perché portano a un tratto allagato) e perciò sono chiuse al traffico, con eccezione per i residenti Questi casi si potrebbero gestire con temporary: - per il ponte: temporary:maxweight=3 oppure temporary:access=no; temporary:foot=yes - per le strade allagate: temporary:access=no - per le strade che finiscono nel nulla: temporary:access=destination ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ponte crollato
M∡rtin Koppenhoefer wrote: 2011/3/2 Paolo Monegatogato.selvad...@gmail.com: Il 02/03/2011 17:42, M∡rtin Koppenhoefer ha scritto: Mi hai fatto venire un dubbio... qualche giorno fa ho modificato il Ponte Pusterla a Vicenza. Dall'alluvione del novembre scorso è chiuso per le macchine perché pare abbia subito danni strutturali. Resta invece aperto a cicli e pedoni. Ho quindi provveduto a segnalarlo come pedestrian (o footway, non ricordo bene) con bicycle=s ed ho aggiunto il semaforo provvisorio che hanno messo poco distante... Devo forse ripristinare highway=classified (o quello che era)? bo. Io lascerei highway=classified, e metterei motor_vehicle=no, foot=s, bicycle=yes, description:it=ponte chiuso per le macchine perché pare abbia subito danni strutturali nell'alluvione del novembre 2010 (oppure una descrizione in inglese, come vuoi). Si potrebbe anche ipotezzare un maxweight=15 ;-) ciao, Martin Sto preparando una proposta per svariati tipi di cambiamenti temporanei - cantieri, eventi, alluvioni - che, una volta approvata, sarebbe la mia scelta per tali situazioni. Secondo me è importante mappare queste situazioni, particolarmente se la durata supera alcune settimane, però è ugualmente importante essere in grado di distinguere, ad esempio, una strada chiusa in modo temporaneo da una strada permanentemente chiusa al traffico. Date un'occhiata... ciao Michael [1] http://wiki.openstreetmap.org/wiki/Proposed_features/temporary ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] manca la struttura nelle Città italiane
M∡rtin Koppenhoefer wrote: 2011/2/28 Simone Saviolosimone.savi...@gmail.com: Sarei d'accordo, ma non mi piace tantissimo il fatto di dettagliare città per città. Mi spiego: se si dice ad esempio le strade importanti del centro sono secondary e quelle che portano al centro sono primary (è solo un esempio), allora questo va messo in una pagina generale (al limite nazionale), ed è una regola che riguarda qualunque situazione. si, quelle regole esistono e dicono che la classificazione è gerarchica e che una primary è più importante di una secondary, di una tertiary, ... Il problema col discorso primary/secondary/tertiary è quello: per la maggioranza dei paesi, la definizione in prima battuta fa riferimento alla classificazione nazionale (strada di importanza nazionale, regionale o locale). Anche per l'Italia, se non ricordo male, le strade statali (a parte delle superstrade) sono di solito delle primary, quelle provinciali sono delle tertiary ecc. Il problema sono i centri abitati oltre una certa dimensione, in cui tutte le strade sono locali. Qui diventa molto più difficile individuarne l'importanza. In altri paesi quel problema non esiste: ad esempio in Germania, le strade nazionali (Bundesstraßen) attraversano dei centri abitati - la circonvallazione di Monaco fa parte della B2 e perciò e primary. Inoltre non dimentichiamo che c'è chi ritiene che nei centri abitati ci possano essere al massimo delle tertiary (cosa con cui personalmente non sono d'accordo, ma vi sono delle opinioni diverse). Come esempio positivo dall'Italia, vi inviterei di guardare Milano, città di notevole dimensione ma comunque, secondo me, mappata bene (il merito è quello degli altri mappatori milanesi - questa struttura già c'era quando ho iniziato a mappare un anno fa). La circonvallazione è primary, e tutte le primary che arrivano al Milano finiscono lì. Il cerchio delle bastioni è secondary; anche al suo interno non vi sono delle secondary. E poi vi è un'ulteriore anello tertiary in centro. Mi ricordo che c'era in discorso su come andrebbe chiuso l'anello al nord-ovest; alla fine abbiamo seguito il limite della zona Ecopass (zona in cui viene ristretto la circolazione di veicoli inquinanti). Ammetto che la soluzione milanese non è trasferibile a qualsiasi altra città. Secondo me bisogna definire delle linee guide per l'uso dei tag. Propongo: - dato che motorway e trunk sono ben definite (segno autostrada su sfondo verde o blù), non c'è niente più da dire su queste due - ove è presente una linea di mezzeria, la strada è almeno tertiary - i collegamenti tra le autostrade, superstrade e primary che terminano nel centro abitato sono primary (tranne quali segnati come autostrada o superstrada) - i collegamenti tra le secondary sono a loro volta secondary, lo stesso vale per i collegamenti tra le tertiary - per determinare i collegamenti, si possono seguire i segni stradali (e.g. il percorso indicato per Vigevano, arrivando a Milano attraverso l'ex-statale del Sempione, è il collegamento tra le due primary interessate e perciò a sua volta primary) - possono aiutare i segni di precedenza [1] - la strada che ha la precedenza dovrebbe aver almeno la stessa importanza di quella che l'attraversa - una primary/secondary/tertiary non finisce mai nel nulla - porta sempre a un'altra strada di almeno la stessa importanza. (Salvo le strade che portano a un luogo d'interesse particolare, es. polo di fiera, o le strade in montagna che terminano nell'ultima località). Con questo si può già risolvere la maggioranza dei casi, dopodiché saranno solo i casi dubiosi da gestire per le singole città. ciao Michael [1] http://commons.wikimedia.org/wiki/File:Italian_traffic_signs_-_diritto_di_precedenza.svg ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Zone italiane con zero mappatura
On 02/27/2011 02:43 PM, Luca Delucchi wrote: Il 25 febbraio 2011 23:07, Michael von Glasowmich...@vonglasow.com ha scritto: [CUT] ... Tutto senza mapping party... si può fare tutto senza mapping party, ma questi secondo me sono molto utili sia a migliorare la qualità della mappa ma soprattutto a vedersi di persona e instaurare un rapporto più stretto con altri mappatori al fine di creare una comunità, cosa che manca completamente in Italia. Ragazzi organizzate mapping party anche se siete solo in due o tre Concordo che aiuta come stimolo. Allora: organizzate delle mapping party se vi va. A chi dovesse non sentirsi in grado: non aspettate che qualcuno organizzi una mapping party, ma andate a mappare comunque. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Zone italiane con zero mappatura
2011/2/24 Stefano Droghetti stefano.droghe...@gmail.com Ho notato che il Polesine, in particolare a est di Ariano Plesine, è mappato zero, Mancano completamente intere città. Non c'è NULLA. Ora, io conosco la zona quindi posso permettermi di implementarne un po' la mappatura, ma mi chiedo: ci sono molte altre zone d'Italia messe in questo modo? Con tutti i mapper che abbiamo, cosa ci vuole adesso che abbiamo PCN a ricalcare le strade principali, perlomeno, in attesa che qualcuno poi passi in auto o in bici a controllare? Invito tutti a guardare meglio attorno alla zona in cui abita in cerca di zone a mappatura zero, ed eventualmente a segnalarlo o a provare a mappare un minimo. È un peccato perché, se per alcune città OpenStreetMap batte completamente le mappe a pagamento, purtroppo per le zone di campagna noto che in molte parti d'Italia è un disastro assoluto. ce n'è da mappare, davvero tanto. Ho visto anch'io che, allontanandosi delle grandi città, la copertura diventa sempre più scarsa. Condivido il mio approccio: l'anno scorso sono stato a Carrù (e altri posti, per la maggior parte in Piemonte). Già prima di andarci ho guardato la zona in OSM+PCN e ho aggiunto tutto quello che si assomigliava ad una strada (taggandolo come highway=road). Lì non ho fatto un singolo passo senza il GPS acceso, ho sorvegliato al volo quando facevamo quattro passi, ho registrato l'albergo dove sono stato, l'osteria in cui sono stato... poi a casa ero in grado di mappare almeno il centro. Tutto senza mapping party... basta mappare al volo quando ci si reca in una zona poca mappata. Se avete dei parenti o amici in una delle zone interessate... la prossima volta che andate lì, portatevi il GPS e tenete gli occhi aperti. Man mano si arriverà... neanche Roma fu costruita (e neanche mappata) in un singolo giorno ;-) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/10/2011 11:01 AM, Dominik Mahrer (Teddy) wrote: If I visit a bus stop by foot I can manage to map the pole/platform. So this could be level 1. But when I visit within the bus, I can only manage to map the stop position. So this would be level 1. What should be level 1 then? All you need when mapping from within the bus is the information whether the stop you've registered is on the left or on the right side of the road (or two facing stops). Then simply place a highway=bus_stop on the appropriate side of the road. Admittedly, this is less precise than visiting the place on foot, but: - when in a bus, the major source of imprecision is degradation of the GPS signal, which often introduces errors of a few meters (more than the width of the sidewalk) and dwarfs the imprecision introduced by guesstimating the distance between the way and the stop node; the location of the pole thus ends up in about the same range of imprecision as the stop position itself - if you have aerial imagery available (preferably from government sources, which tend to be more precise than Bing and the like), in many cases you can make out some features of the bus stop on the images - the shelter, road markings, a widened/narrowed sidewalk - and fine-tune your position with that - when all else fails, you can always leave a fixme tag, explaining that the position of the stop is approximate and other mappers should feel free to correct it As for defining the levels, I would define level 1 as the simplest scheme in terms of learning curve, and when in doubt, opt for the tags with the highest diffusion. So here I'd definitely go for highway=bus_stop on level 1. And I do not think we (mappers) can replace an existing public transport routing solution like hafas (too complex and too dynamic). There have been calls for this. IMO it is feasible, but as a layer on OSM, not within. Maybe, you are right. But then the next question that pops up is: Do we then need the bus routes within OSM at all? Wouldn't it make more sense to move them to this new layer? Transiki, as I have understood, aims to provide this layer on top of OSM (in fact going even further than just routes). If you're looking for the 100% solution, maybe that's the place to develop it. On the other hand, Transiki isn't there yet and I don't even know where it's going. What I am certain of is that OSM can represent public transport routes, possibly with some concessions on precision (such as not handling some route variants). Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Come risolvere lo sfasamento del satellite?
Federico Cozzi wrote: 2011/2/10 Stefano Droghettistefano.droghe...@gmail.com: stesso identico percorso. Lo spostamento è del tutto casuale, e copre errori anche fino a 6-7 metri. Errore fisiologico del GPS, non puoi sperare di fare meglio con apparecchi normali (e soprattutto in città). E soprattutto capita immediatamente dopo di aver preso il primo segnale - il GPS ha bisogno di un po' di tempo per stabilizzarsi. Quando tiro fuori il mio cellulare e comincio a registrare subito, i primi metri del percorso spesso non corrispondono nemmeno lontanamente alla realtà (errori di 10-20 metri). A un certo punto la precisione si migliora - se la ricezione e buona. Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/08/2011 09:17 PM, Dominik Mahrer (Teddy) wrote: Here we're getting into one of the uglier parts of transport mapping - large terminals (amenity=bus_station) with multiple stop positions and platforms. I deliberately left that out of the proposal I presented (my plan is to present that as a later extension). Do you have an idea how it will look like? Well, a rough one: So far we've had amenity=bus_station tagged as a node or area for the whole thing - I think this makes sense to keep. In many cases buses have a fixed platform at which they stop. Hence, we need * a node/area for each platform/boarding position * a tag which designates it as such (some candidates are already in use) * a name or ref (where one exists on the ground) Then, we need some way to associate the platforms with the bus station: * if the bus station is mapped as an area, platforms must be within the station * if the bus station is mapped as a point, take the point which is closest to the platform * as an alternative, just use a relation - then we might as well drop the extra node/area for the bus station and apply the type=amenity; amenity=bus_station tags to the relation instead; renderers could then display an icon on the centroid and/or draw the convex hull of all members Not sure about this one yet, though, especially about the third alternative. Representing the whole bus station as a relation, in combination with being able to add the bus station as a whole to a route relation (see below), would introduce nested relations, which I realize some people don't like... Finally we need a way to add bus stations to route relations: * If the bus line has a designated platform (which may also be used by other buses, but the line in question may not stop at another), and you know it, add that with role=stop. * If the bus stops at different platforms depending on the time of the day or other factors, add the whole bus station with role=stop. * If you just don't know at which platform the bus stops, add the whole bus station (like above). If you've found out the details for a bus route, replace the bus station with the platform in the route relation. If the platform is a member of the relation, there is no need to add the bus station as well - in the best case this is convenience tagging, in the worst case it may actually confuse renderers (two members for one and the same stop). Line sketch renderers should use a combination of bus station and platform name/ref, where available: Assuming name=Terminal West for the bus station and ref=D for the platform, this could be rendered as: Terminal West, Platform D (note that the string Platform would be supplied by the application itself). If the platform has no name or ref, or the relation contains the whole bus station, just use the name of the bus station (as with an ordinary bus stop). But that's still a rough idea in my mind... Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/07/2011 11:11 PM, Richard Mann wrote: On Mon, Feb 7, 2011 at 9:40 PM, Michael von Glasow mich...@vonglasow.com wrote: http://www.openstreetmap.org/browse/relation/611446 Single-direction, the first stop (Bonola) is a platform member (no stop member exists for this one); all others are stop members. Both directions rendered: http://78.46.81.38/api/sketch-line?network=SITAMref=80style=padua As far as I can tell the sketch-line ignores the highway=platform/role=platform ways. I think Bonola renders because it's a stop and a platform in the reverse direction relation: http://www.openstreetmap.org/browse/relation/611538 Ouch... you're right, that's why I added the public_transport=stop_position with the stop role, sketch-line wouldn't render the platform alone. It's been quite a while since... Here we're getting into one of the uglier parts of transport mapping - large terminals (amenity=bus_station) with multiple stop positions and platforms. I deliberately left that out of the proposal I presented (my plan is to present that as a later extension). Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/07/2011 10:45 AM, Richard Mann wrote: Can anyone point me to a route relation with platform stop members, so I can check how the line-diagram service works in that situation? http://www.openstreetmap.org/browse/relation/611446 Single-direction, the first stop (Bonola) is a platform member (no stop member exists for this one); all others are stop members. Both directions rendered: http://78.46.81.38/api/sketch-line?network=SITAMref=80style=padua Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/05/2011 06:09 PM, Richard Mann wrote: On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow mich...@vonglasow.com wrote: if I may just comment on the relation: I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) You have to use forward_stop and backward_stop if you combine the two directions in one relation, otherwise the same-named stop in the two directions don't get combined on the line diagram. You're probably right (though I haven't tried plotting spoon lines yet), when the same stop is served twice, the tool needs that information. stop works well for single-direction relations. Maybe it would be best to use forward_stop and backward_stop for the stops which are served in both directions and stop for the stops in the loop. Then again, I'm wondering whether that's too much tagging for the renderer already. Couldn't a well-written renderer look at the stop names and deduct from these the fact that the stop is the same? Or can you think of any case in which that wouldn't work? I think if you use two relations, one for each direction, it combines them regardless of role (and even if there's no role). I did a lot of experimenting to get a simple, one-relation-per-direction line to render correctly. If I remember that correctly, the stop role is required (forward_stop, backward_stop or platform will also work). The tags on the members also seem to matter (e.g. amenity=bus_station, even with the correct role, does not get rendered.) Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/04/2011 12:09 PM, Richard Mann wrote: I've been attempting to order a relation using P2 (I don't recommend trying it yourself yet - the process needs streamlining). I managed to sort the nodes in a two-directions-with-loops relation: http://www.openstreetmap.org/browse/relation/85299 and got a reasonable line-diagram, once I'd added forward_stop and backward_stop: if I may just comment on the relation: I would start and end at the terminus (which seems to be The Oval) - that way the relation represents the longest way a passenger can travel (assuming services don't normally end at some point in the loop), which I think is most intuitive. I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) http://78.46.81.38/api/sketch-route?85299 I think this confirms that line diagrams will work fine with stops beside the way. In fact - as I understand it, the tool ignores ways completely and just examines stop members and their order. As far as I know, retrieving the stops of a line on openbusmap works the same way. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/03/2011 12:04 PM, Richard Mann wrote: On Thu, Feb 3, 2011 at 5:40 AM, Dominik Mahrer (Teddy)te...@teddy.ch wrote: I do not think it is a good idea to redefine thousands of used railway=tram_stop. The problem is that railway=tram_stop is used to mean a number of different things, which have different geo-locations when you start mapping in more detail. You are emphasising one particular meaning (the stop area centroid), and other people emphasise another meaning (an indicator of the boarding location). We can't know which is dominant. To ensure basic compatibility, I suggest all schemes should use nodes tagged railway=tram_stop, and make them ordered members of the route relation with role=stop (or maybe forward_stop/backward_stop). I don't think we need to be prescriptive about where those nodes are placed, just tell people there are two basic options (on track or either side of the track). I think the simplified scheme probably _recommends_ these nodes should in due course be beside the track, and possibly on platforms, and that something else (railway=tram_station) should go on the centroid as a courtesy tag. I agree that the courtesy tag probably won't hurt much if mappers decide to use that. I would in fact tend towards using public_transport=stop_position, as suggested by Dominik, given that it's already being used. (While I consider that beyond the scope of the proposal, we might still keep it in mind for a future amendment). In fact, even if we decide on placing tram stop nodes next to the way, I don't think the existing nodes will do much harm. They continue to be perfectly valid - the only information they lack is which side of the track they are on. It's the equivalent of representing a parking lot by a single point tagged amenity=parking, or one single way tagged railway=rail going into a railway terminus of 20 or 30 platforms - not incorrect but just not very detailed. I wouldn't start a cleaning binge in my area, during the course of which I move all stops - I'd probably update them on the fly when I'm editing in the surroundings anyway. However, making the position of the tram stop a recommendation (on the way is OK, but next to the way is detailed and thus preferred) sounds like a good compromise. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Bus/Tram/Metro paths export
Ciao Tiziano, I think I recently came across something which may be of interest to you - though I haven't yet tried it myself: http://svn.openstreetmap.org/applications/rendering/subway/ This script creates a network sketch (a crude form of the London tube map) from OSM data. To make it a tube map, you'd need to move points around using a vector graphics editor, the raw output seems to be much like the example you sent. Hope it helps Michael On 01/27/2011 11:31 AM, Tiziano D'Angelo wrote: Hello, after doing so much work onto bus/tram relations in my city Padova, I'd like now to extract some geographically exact paths of single routes from OSM database, possibly in SVG format, and use them on a Padova-PT website I am going to build soon. Most of you are probably familiar with http://78.46.81.38/public_transport.html , and I can already obtain sketches of the routes, but my aim is to obtain something with this output: http://upload.wikimedia.org/wikipedia/commons/9/9b/Ligne_4.gif for just a single line like in the example, or also with more lines (selecting for example all evening lines, or all Sunday lines). In this case, for a simpler rendering of everything, the stops aside the way should be coupled together if they have the same name (as in OPNVKarte) and the corresponding dot should be part of the drawn route. I do not have extendend programming skills, therefore I don't know how to obtain it, can somebody help? Thanks Tiziano ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Following the call for a better proposal, Tiziano, Oscar and I have drafted up a simple proposal. It is based on how we have mapped the public transport networks in our cities (Padova, Ferrara and Milan), with some improvements that came up during this discussion. Our approach was to keep it simple, therefore we have deliberately not treated special cases. For now, we want to standardize the basics; once we have agreed on those, we can discuss special cases which might not be covered by the current proposal and draw up an amendment, to be decided separately. You can find the proposal at: http://wiki.openstreetmap.org/wiki/Proposed_features/Simplified_Public_Transport_Scheme Constructive feedback and suggestions are welcome and can be sent to the list or left on the proposal's discussion page. Michael OSM Mapper of the public transport network in Milan, Italy On 01/14/2011 11:52 AM, Oscar Formaggi wrote: I agree with Tiziano. I am among those interested in joining. Oscar OSM Mapper of the whole city bus network in Ferrara, Italy 2011/1/14 Tiziano D'Angelo tiziano.dang...@gmail.com mailto:tiziano.dang...@gmail.com How about you, [...] develop a better proposal? We seem to share the understanding of the flaws; a new proposal may lead to a secession, which is the ugliest thing possible, but I am not sure we can continue to improve the current proposal. I am in :) and the proposal should aim also to keep the existing status quo for backwards compatibility (i.e. highway=bus_stop as the essential basic element of a bus stop). I know there are more people who are interested to join. Tiziano OSM Mapper of the whole city bus network in Padova, Italy ___ Talk-transit mailing list Talk-transit@openstreetmap.org mailto:Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 01/27/2011 11:37 PM, Jo wrote: route_ref does not seem obsolete to me. True, if the relation is defined, it can be determined from that by routers. But as long as that hasn't happened, this is the information that a mapper can take not of in the field. That's basically what I meant - you don't need it if there is a relation for each route and the stop is a member of it, but in absence of relations it can be useful. I'll change it from obsolete to optional. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Fwd: State of the Map Europe - Italian
Maurizio Napolitano wrote: Confermo: S =traßenbahn, letteralmente binari stradali, ergo Tram No, S sta per Schnellbahn, servizio ferroviario suburbano (paragonabile alle linee S a Milano). Vi sono anche dei tram, queste linee vengono identificate da una singola lettera (D, J, ...). U =-Bahn, la U sta per Unter, ovvero sotto, quindi binari sotterranei, ergo Metropolitana però, per aumentare la confusione, vi è anche un passante ferroviario, servito dalle linee S... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Public Transport Line Diagram
On 01/26/2011 08:43 AM, Wojciech Kulesza wrote: Just compare your relation with the working one :) http://www.openstreetmap.org/browse/relation/361959 On first sight i'm wondering why you are mixing railway=halt and railway=tram_stop? Isn't all of it a tram line? Additionally you are missing from= and to= in your relation. Claudius This was maybe not clear from my first email. I was not the author of those relations. I simply used openstreetbrowser.org http://openstreetbrowser.org project to identify already-existing relations for trams/buses in Poznan/Poland and used them in that OSM API. Is there anything i can do in order to get them in the correct format? I already got involved in some editing of OSM, through Portlach (flashbased tool), but this was more on adding some missing escalators and fixing non-connected islands in case of intersections. I had to experiment a while to get my relations to be displayed the way I wanted; if I remember correctly, you need to: * tag your relation as type=route; route=light_rail/subway/tram/bus (note that route=trolleybus is not supported, you'll get No relation found) * set the ref=* and network=* tags correctly * not sure if you also need from=* and to=* but for sure it doesn't hurt (and the values get displayed, so it'll look better if you have them) * add your stops with role=stop and make sure they're sorted correctly. There seem to be some restrictions on the stops and their tagging. As long as all stops are single nodes (not areas) and tagged as one of the following: * railway=station * railway=tram_stop * highway=bus_stop * public_transport=stop_position you should be fine. (Note that amenity=bus_station does not work.) This will also work for lines mapped with two relations (or even four for Y-shaped relations). Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Aggiungere tag Preimpostati in JOSM
Fabri wrote: Vorrei che nelle prossime versioni di josm, fosse inserito nei preset, nella categoria strutture -- svago, anche il tag leisure=dog_park. Come si può fare? Devo aprire un ticket? O creare una patch? Credo che per un preset basta aggiungerlo al wiki di JOSM [1]. Prova ad aggiungerlo, poi dovresti vederlo in Edit Preferences in JOSM. Bisogna comunque attivarlo per poter utilizzarlo. Se però vuoi che il tuo preset sia disponibile senza che l'utente debba esplicitamente selezionarlo, andrebbe aggiunto a defaultpresets.xml [2]. Per questo ci vuole un ticket, che puoi creare visitando [1]. Se hai la patch (o puoi crearla), allegala pure al ticket. Sarà sicuramente apprezzato ed accelererà l'integrazione in JOSM. [1] http://josm.openstreetmap.de/wiki/Presets [2] http://josm.openstreetmap.de/svn/trunk/data/defaultpresets.xml ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] funny signs
Assolutamente... ho già aggiunto una curiosità che avevo incontrato io. PS: guardando il nome dell'altro immagine mi chiedo se siamo solo noi crucchi a vedere queste cose...? Sarà che siamo troppo pignoli... M∡rtin Koppenhoefer wrote: Ho appena scoperto questa pagina del wiki. Penso che la possiamo aggiornare con altri esempi dalla nostra vita mappatoriale italiana? Un imagine solo mi sembra indegno ;-) http://wiki.openstreetmap.org/wiki/Funny_signs ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Route e ruoli
Simone Saviolo wrote: Ciao, sembra che le route la facciano da padrone in questi giorni :-) Questa è più una domanda da tagging, ma come mia abitudine vorrei prima avere un'idea di come altri mapper italiani affrontano il problema. Si è detto che (come documentato sul wiki) le linee dei tram o dei bus vanno rappresentate con una relation route nella quale le way delle strade vanno inserite come forward o backward a seconda che la linea vada nel verso della way oppure al contrario. Questo è logico per una linea del tram: la linea 5 va da A a B, e se una way è disegnata da B ad A viene inserita come backward. Esatto, al momento viene taggato così. Abbiamo però avuto una discussione su talk-transit, in cui è stato proposto di abbandonare le relazioni bidirezionali (una singola relazione per andata e ritorno) e non usare più i ruoli backward/forward: se poi le way sono ordinati nella relazione, si può facilmente risalire alla loro direzione (dal nodo comune con la way precedente fino a quello condiviso con la way successiva). Per le route di tipo road, però, la cosa non è così semplice. Faccio un esempio: la Statale 31 collega Vercelli ad Alessandria, e, per definizione, ha il km 0 a Vercelli, dove si raccorda con la SS11. In questo senso (e poiché sono di Vercelli ;-) ), nel fare la relation ho messo le way in ordine da Vercelli ad Alessandria, e ho segnato come forward le way che si percorrono *solo* da Vc ad Al, come backward quelle che si percorrono *solo* da Al a Vc, e come route quelle che sono condivise dai due sensi di marcia. Questo mi è stato reso necessario dalle strade a senso unico, tipicamente svincoli o corsie di ingresso nelle rotonde. Il problema è che ho dato una semantica diversa ai ruoli; ma la semantica delle linee del bus non mi sembra adatta. Se si può dire che la linea del bus va da A a B, e quella che va da B ad A è *un'altra* linea del bus, una statale rappresenta il collegamento tra due località, non un percorso orientato da A a B. Non mi sembra giusto fare la SS31 e la SS31 reverse, perché non esiste la differenziazione. Del resto, in questo caso dire che una way è forward perché è orientata da Vercelli ad Alessandria non ha senso: chi fa la strada inversa la considererà backward. Chi ha dovuto affrontare problemi simili, e cosa avete scelto di fare? Non basta inserire le way senza nessun ruolo? Quelli che si percorrono in una singola direzione di solito sono taggati oneway=yes (ovvero junction=roundabout) - non vedo che valore aggiunto abbiano i ruoli in questo caso. Concordo che un bus è un caso diverso - una corsa va da A a B, l'altra invece da B ad A, mentre la SS31 va da Alessandria a Vercelli *e viceversa*. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/09/2010 01:31 PM, Michał Borsuk wrote: On 8 December 2010 20:44, Dominik Mahrer (Teddy) te...@teddy.ch mailto:te...@teddy.ch wrote: Hello Yes, the Public Transport proposal is basically based on Oxomoa, but in some details different. I do not care about which of the two proposals will be approved. But I think it is time to get a more exact schema approved then the fuzzy/non-existing schema (A railway station of 400m length and 20 platforms or a bus stop for 3 buses per direction of 50m length is reduced to one node) we have now. There is the issue of multiple relations per line in oxomoa, which in my opinion is a total misfit. There are roles in relations, and different variants of a route can be put there. My previous post to this list contains an example of what you may encounter in real life. The case of a telescope line may be representable in a single relation, but I really do not know how to express in a single relation that some courses skip part of the route (the market example) and follow another (including some different stops) instead. If you have a decent way of expressing that in a single relation, please do share it here - I'd happily adopt that if only someone suggests a satisfactory solution to the issue. Two, or more, relations per line is not only illegal (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Are you referring to the master relation which contains the relations for the route variants? In fact I don't use them in Milan (in Munich it seems common practice and I follow that), and as of today renderers seem to be fine even without it. Take the following example: http://78.46.81.38/api/sketch-line?network=SITAMref=69style=padua This line is made up of four relations (two variants with one relation for each direction), and OSM Server Side Script manages to put them together based on their ref and network tags. Obviously, the individual relations must have all the tags that would otherwise go into the master relation. Or do you mean the fact that there are two (or more) relations per line? It is true that it means more effort, which is why I would happily consolidate the information into a single route if this were doable without losing information. Editor support, as Dominik writes, I would not overestimate. JOSM may be complex, but maintaining public transportation routes is complex on itself - someone doing that is quite likely to use JOSM anyway. I don't really see a reason against using JOSM - Potlatch in my opinion is for the occasional mapper or for very quick edits; Merkaartor may have some performance benefits (being a native application) but JOSM still has satisfactory performance. Potlatch and Merkaartor account for 2/3 edits together. Now this does surprise me - I would have expected a higher market share for JOSM. If you have the figures at hand, it would be interesting to find out how many of the people who edit public transportation data use JOSM vs. other editors. Then again - if other editors do not support all that's possible, we should also consider adapting the editors to support the tagging scheme we have in mind rather than adapting the tagging scheme to what is supported by all editors. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/09/2010 06:35 AM, Dominik Mahrer (Teddy) wrote: Hi Michael In the new proposal I am missing some details on how to build relations: 1. Should the outward and return trip be represented as two separate relations, as a single relation or is that up to the mapper? Each direction should be in a separate relation. This is written in the proposal. Both directions/variants should be member of a master relation. you're right, I overlooked that. I already use separate relations for each direction so I agree on that unless we find a convenient way of reducing the number of relation needed. I don't use master relations - in most cases, the relations of a single line are sufficiently identified by their ref and network. There may be exceptions, though: the network name is not guaranteed to be unique, and in that case it may be difficult to separate two lines with the same network names which in fact belong to different networks. Plus, here in Milan line variants are often (not always) indicated by adding a slash. For instance, line 42/ may mostly follow line 42 but serve some extra stops not served by 42 (and, in some cases, skipping the last stops of 42). 2. Which members should the relation contain, and in which order? You are not the first with this question, so I added some explanations to the proposal: First the stop_positions ordered (with role stop), then platforms ordered (with role platform) and then the ways ordered (without role). 3. Which data primitive should be added for stops? Stop positions AND platform. Stop position is important for the route itself, the platform is important for pedestrian routing. Fine for me, though it does mean some more effort to enter data. Except that we might consider adding the platform right after the stop it belongs to - that would make it easier to verify that both are there. 4. How are line variants mapped? Problem 1: A - B1/B2 - C - D - E1/E2 - F In morning and evening hours the bus stops at B2 instead of B1. During school holiday the bus stops at E2 instead of E1. This gives us four possibilities really used. When you add alt-roles to a stop you can't say when is what route used. So this does not work, we need really four relations. Yes, this is a more complex variant of my market example (yours is the equivalent of two markets, say, one on Monday and Wednesday and the other on Wednesday and Friday). As I mentioned in my post, I have no feasible solution for mapping this in a single relation. Problem 2: What do you want to say with role forward/backward? Forward/backward compared to what? To the route direction or to the tagged way direction? Actually both is used in the OSM database and no one knows how to interpret it. Role forward and backward is in my eyes a nice try to solve a problem. But it confused more then it solved. We should leave this away. As far as I know, this is accurately defined: it is relative to the tagged way direction, which may or may correspond to the route direction. But I, too, realize that this part confuses people. If we agree that ways must always be sorted, each way sharing an end node with the ones before and after (which I strongly recommend), then we can extract this information from the route itself without tagging it explicitly. Practical: I map the variant with the most stops (in your example twice A B1 E1 K. In JOSM you can easily copy a relation and change what is different. So to handle your 8 variants should not take 8 times mapping one variant. That works when you have the entire route from beginning to end. But some of us (I do) often follow just a part of the way and enter that, hoping to complete it at a later occasion (or someone else doing it). And once you have two partially-complete relations, updating them both together mostly means editing each relation manually. I personally leave away the very special cases (ex. first course starts at B instead of A). This is only relevant when timetable information is added to. For some applications, namely public transport maps and route sketches, this information might still be useful. For instance, those parts of the route which are omitted by some courses could be represented as a dashed line, the rest being drawn as a solid line. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Again about time tables, and some interesting sites
On 12/06/2010 05:07 PM, Michał Borsuk wrote: Am 06.12.2010 15:26, schrieb Andrei Klochko: Hello, Yes, in France it's even worse: the database producer may forbid any quantitatively or quantitatively substantial extraction from his database, by all means and in any form BUT you have this counterpart: when a database is made available to the public by the holder of the rights, then he cannot forbid [among other things] the extraction AND reuse of a quantitatively or qualitatively non substantial part of the database, by the person who has licit access to it. So after all us, the grumpy old men, were right. I only put this line here, to ask the question: what, if many different people, decide to all take one timetable, and then reuse it as they want, like for example, by publishing it in a centralized site? Then this is the wrong group. Ask a lawyer! Indeed talk-legal may be the more suitable list for such discussions. As for database copyright, I can tell you the situation here in Italy (and I would expect the situation to be somewhat similar throughout the European Union): Database copyright applies to databases in any form, even non-electronic (think printed telephone books), though I'm not completely sure about how non-trivial a database has to be in order to be copyrightable. In any case, the copyright extends to any substantial extraction of data (again what is substantial is not well-defined and may be a gray area). Even if it's done in tiny bits, one record at a time, as soon as these are put together again, they will become substantial as soon as enough data is gathered (IANAL, the interpretation is my own). However, let's assume the following: * Public transport companies have a database of all their stops, lines, timetables etc. (Organizations that have existed for decades might originally have kept this information on paper, but as we have seen before, even this may legally be a database.) * That database was created beforehand, only after that were the stops built and lines entered into service. * Hence, the fact that there is a stop, its name, location, lines and all the rest are all data derived from that company's database. * As a result, even mapping bus stops (let alone lines) would be a breach of copyright unless *either* we have permission from the company *or* it turns out that the original database is not copyrightable for some reason. The same may apply to other fields of OSM, such as information on street names. In their case, however, the decision to name a street in a certain way is a legal act or regulation and, as such, cannot be copyrighted in many countries. Public transport infrastructure may or may not be a similar case. In fact I remember that at one of the last SOTMs (2009 or 2010 I believe) there was a lawyer talking about the legality of mapping streets and others, and the key message was: It's a gray area, but don't let that discourage you from mapping. Here the data is made publicly available...and if the transporters are the ultimate producers of the data, then taking it from every transporter is only copying THEIR database, which is not big enough to make a database. You see? No, I don't. The catch is that the aggregation of these single databases may constitute sufficient effort to qualify as a new database. On a different note: have you taken a look at Transiki yet? In case you haven't, it's Steve Coast's second child after OSM and their goal is just that - to make public transport timetables freely available. You might want to get in touch with them - they seem to have an idea similar to yours and are still in their beginnings, maybe you can join forces. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] PCN e Bing
On 01/-10/-28163 08:59 PM, niubii wrote: Il giorno 06 dicembre 2010 16:18, M?rtin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com ha scritto: C'è un layer WMS per Bing da usare??? Si, c'e' nell'ultima release di WMSplugin, ma non funziona (tiles rosse con messaggio di errore). Ciao /niubii/ A me funziona; bisogna però stare attenti su due cose: - con Linux alcuni fonti (tra l'altro Yahoo e Bing) funzionano solo dopo di aver installato un'altro pezzo di software e aver modificato un'impostazione in JOSM; senza di questo ti dà solo Exception occurred su fondo rosso. Per verificare - se riesci ad usare Yahoo, dovrebbe funzionare anche Bing. - Vi sono alcuni livelli di zoom predefinite. Con un livello di zoom troppo fino (più di quello disponibile) vedrai solo delle tiles rosa/rosse (coll'icona dell'immagine rotta in alto a sinistra). Con un livello di zoom di indicativamente 70 metri dovrebbe funzionare; delle risoluzioni più fine sono disponibili solo in alcuni posti (centro città grandi). ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] edit public domain e fonti esterne
On 01/-10/-28163 08:59 PM, iiizio iiizio wrote: 2010/12/2 Niccolo Rigaccio...@rigacci.org: On Wed, Dec 01, 2010 at 05:39:50PM +0100, iiizio iiizio wrote: Non mi sembra la stessa cosa: You have also declared that you consider your edits to be in the Public Domain. Chi dichiara di fare le cose in public domain deve verificare di non violare il copyright di altri, quindi deve selezionare le proprie fonti compatibili con il PD. La dichiarazione PD dell'utente ha comunque poche possibilità di tradursi in qualcosa di utile per OpenStreetMap, visto l'intreccio inestricabile con il lavoro fatto dalla gran massa degli utenti, che usa (per scelta propria o altrui :-) una licenza diversa. Vista cosi sarebbe da chiedersi perché OSM ha messo questa opzione che porta solo svantaggi a OSM stesso. Leggendo qui [1] le cose stanno diversamente (tradotto dal tedesco, evito la doppia traduzione): If you explain that you your posts in the public domain (Public Domain) viewing, which is only a statement of intent. You change the fact not the license, and it has no influence on what your users can do with data. The database right has priority over the protection of individual data elements. Users must abide by the ODbL if they want to use OSM, even those collected most of the contributions of participants who consider their data as public domain. However, such statements will have a major impact. As participants for the option to decide many public domain, will have an impact on how the opinion on the subject of license for OSM developed the future. Nothing is absolute, the ODbL can either be strictly enforced or handled lax. If you clicked the Select Domain Public, you give it were known: All right, folks, takes ODbL-thing by it if you must, but do not overdo it. I look at my posts in the public domain and would prefer to deal with maps as to what is now allowed and what is not. A questo punto è sbagliato il wiki o la frase in My settings e quella del checkbox (In addition to the above agreement, I consider my contributions to be in the Public Domain) quel inglese è davvero wurstel-e-crautico (Google? perciò gente chi non credono che computer potrà a pensare come uomini anche non credere in macchina traduzione), Allego una traduzione del originale tedesco: Se dichiari di ritenere i tuoi contributi in public domain, *è solo una dichiarazione di intenzione. Non modificherai la licenza e non ha nessun impatto sulle cose che possono fare gli utenti con i tuoi dati.* Il diritto d'autore sulla database ha la precedenza sulla protezione di elementi individuali di dati. Gli utenti sono tenuti a rispettare l'ODBL, anche se la maggioranza dei contributi è di contributori che ritengono i loro dati in public domain. Tali dichiarazioni di intenzione possono comunque avere un'influenza notevole. Il percentuale di contributori che scelgono Public Domain avrà un'impatto sul sviluppo futuro delle opinioni sulla licenza di OSM. Niente è assoluto, anche l'ODBL si può applicare in modo rigido o meno. Scegliendo Public Domain sostanzialmente stai dicendo: Va bene, ragazzi, andate avanti con quella roba di ODBL ma senza esagerare. Considero i miei contributi in public domain e preferirei dedicarmi alla mappatura piuttosto che chiedermi cos'è ammesso o meno. [1] http://wiki.openstreetmap.org/wiki/DE:Editing_Why_would_I_want_my_contributions_to_be_public_domain ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] Public transport on the main OSM page
*Dominik Mahrer (Teddy)* wrote: http://wiki.openstreetmap.org/wiki/OSM_Inspector provides a similar view (Public Transport Network) like ÖPVN-Karte. Yes, I know that site - it's good for debugging OSM data but not really a site I would recommend to a non-techie who just wants to know how to get from A to B. That is the great strength of Öpnvkarte. *Sébastien Aubry* wrote: There are two ways to proceed: - like you said, this could be added to the default OSM map as a layer. To ask for such a feature, we should create a ticket on the OSM trac: http://trac.openstreetmap.org , perhaps on the mapnik component ? You're right, I should have thought of that :-) - we could provide Transiki with these ideas. This default, simple map could be the first step of this initiative, allowing us to move further by inputting the schedules in the next steps. Not a bad idea - in fact, I have only heard of Transiki but not looked at it in detail, but I guess this is something they might be interested in. Though Transiki would be primarily a user, but maybe joining forces helps us get more people who are interested, willing to contribute ideas and work and so on... We could also ask the creators of openbusmap if they would agree to open their code. Yes, I thought of that, too. I'll get in touch with Melchior to see if he's willing to share the work he's already done. *Sander Deryckere wrote: * / Step 1: Add the new map view / / // Create a new Mapnik style sheet with routes and numbers overlaid on it.// / / ////all rendering-related effort I would expect to roughly double as //every tile would get rendered twice (once per style).// // / This woudn't cause mapnik to render double. I believe mapnik only renders when a tile is visited and changed, or after a longer period. As long as nobody visits the tile, it wouldn't be rendered for a long while. I was generalizing: Mapnik, to my knowledge, renders tiles only when they are viewed and either dirty (changed since they were last rendered) or more than a week old. So the rendering effort for the current Mapnik style would remain roughly the same, but there would be extra effort to render the new style (if it gets viewed). If someone switches from one view to another, this may result in the viewing area being rendered twice, and finally I have made the bold assumption that a public transport map would get us some more traffic. In fact, our mileage may (and probably will) vary. As for rendering both styles together: that's a performance and tuning issue we might want to look at... / Step 2a: Line sketches // //The only problem is that the output is in SVG format, which //not all browsers out in the field handle well: we may need to convert that //into a bitmap on the fly. / I believe most power users don't use a ie browser. So if they are not power users, the extra clicks to download and view it are small. So converting it is not really needed. True for power users, but I'm envisioning a grandmother-proof solution (i.e. a website that even your grandmother will be able to use without problems). Thanks to all of you for your input so far. Further ideas are always welcome, of course. I'm thinking of setting up a Wiki page (along with a ticket) as a central brain for these efforts and will keep you up to date. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Fwd: [OSM-talk] Steve Coast Joins Microsoft as Principle Architect of Bing Mobile
G Zamboni wrote: Il 24/11/2010 0.31, G Zamboni ha scritto: Il 23/11/2010 20.18, Tiziano D'Angelo ha scritto: Il fatto che Microsoft non mi sia per niente simpatica non conta quasi niente. Quello che conta è che lo foto della mia zona sono scadenti: vecchie di almeno 7/8 anni (e comunque più vecchie di quelle Yahoo) e con scarsa risoluzione (non di molto ma comunque inferiori a quelle Yahoo). Dimenticavo che sto parlano di Venezia, non di una landa desolata. Certe città come Milano, Roma, Napoli e Bari hanno delle ottime foto, a Genova ad esempio si sono limitati al centro. Proprio la città giusta per fare i tirchi :-)) Sono certo che per qualcun'altro (all'estero) sarà diverso, ma, ammesso e non concesso che le foto vengano rilasciate con licenza compatibile, per quanto mi riguarda questa notizia non mi porta alcun vantaggio nell'attività in OSM. Le foto del PCN e i dati della regione veneto sono parecchio più utili. Dopo di aver guardato alcune zone che conosco, le foto variano sia nella risoluzione che nella loro età. Alcune ortofoto di Monaco sembrano di risalire all'estate 2005; le foto di Milano sembrano scattate un giovedì in ottobre/novembre 2007. Qui sono infatti più recenti di quelle del PCN, ma la qualità no è sempre il massimo (se fate zoom sulla fiera di Milano, vedrete degli effetti interessanti - alcune foto del periodo prima dell'inizio dei lavori, altri del periodo dopo). In quanto alla precisione - si vedrà una volta abbiamo il link per OSM in modo ufficiale. Insomma - ci rimarranno dei motivi giustificati per continuare ad utilizzare il PCN; per Milano io probabilmente userò tutti e due - uno per avere delle georeferenze affidabili, l'altro per avere i dati recenti ad alta risoluzione (o caso mai mi dovesse bannare il primo :-) ovvero quando mi capita a spingermi oltre le confini italiane. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-transit] Public transport on the main OSM page
Hello list, For my efforts mapping public transportation routes in Milan, I have up to now relied on Öpnvkarte to look at the data I entered and occasionally look up the best way to get around town. In the meantime the situation has changed: Öpnvkarte hasn't been updated since early September; a similar service at latlon.org has discontinued coverage for Western Europe (they seem to have limited themselves to Belorussia, Russia and maybe some of their neighbors) and the third player in the field, OSM Transport, comes with disadvantages (slow to load, slow to update, less nice to use and not open-source). Couldn't we do something similar right on the OSM homepage, running on OSM infrastructure? The advantages would be: - Easy switching between normal and public transport view (just a matter of switching base layers) - Only one URL to remember - Uses most recent data (if directly connected to live OSM database) - Standard OSM tools available (for instance, exporting the map as PDF) - Could be a killer app for OSM (until now this information is available only for single networks from their respective transport companies, if at all; OSM would be the first to do this for the whole world) Following the iterative approach with which OSM was and is being built, here's how it could be implemented: Step 1: Add the new map view Create a new Mapnik style sheet with routes and numbers overlaid on it. I would suggest the familiar Mapnik view but in black and white (at the most I would color some landuses), possibly reducing the number of POIs if the map gets too cluttered. All stop names would be shown; routes and their numbers would be drawn in color on top of everything else. This would preserve all information but make public transport data stand out. This should be fairly easy, it would take a second Mapnik style sheet and possibly some post-processing to render the routes. The database is already there; all rendering-related effort I would expect to roughly double as every tile would get rendered twice (once per style). Not sure about the effort to run Mapnik with two different styles. Step 2: Add stop information Add a new overlay, which makes all stops clickable. Clicking on a stop opens a bubble with information on it, such as name and lines stopping there. This would require some extra coding, but most of the work has been done already (e.g. OpenStreetBugs, which has an overlay for clickable bugs). Some extra post-processing will probably be needed on the data in order to group nearby stops belonging together (take Munich's central station, which consists of one light railway stop, two subway stops, three tram stops and a couple of bus stops): that way the user just needs to click the station and gets a popup with all the light railway, subway, tram and bus lines. Öpnvkarte already does this, so it's not impossible. Step 2a: Line sketches In the popup for each stop, clicking the line number opens a new window with a sketch of the line. Probably easy play: Sketch Line from OSM Server Scripts [1] (example [2]) already does an excellent job at this; just the choice of colors may need some tweaking. The only problem is that the output is in SVG format, which not all browsers out in the field handle well: we may need to convert that into a bitmap on the fly. Step 3: Extensions Up to the imagination of the community: For example, if one day we add routing to the OSM page, we could extend that to finding a public transport connection. Taking Milan as an example, step 2a would already put us ahead of what Google has to offer today: Transit is not available for Milan yet, bus stops are missing completely on the map, the location of subway stops is approximate at best and the network data seems to be out of date. Now here's the catch: While I am ready to contribute to such an effort, I cannot do it alone - my knowledge of the OSM infrastructure is generic at best. Is there anyone out there who: - knows how to get started in order to get new items on the main OSM page, in terms of both technology and who to talk to? - is willing to participate in such an effort? Any input is greatly appreciated. Michael [1] http://wiki.openstreetmap.org/wiki/OSM_Server_Side_Script [2] http://78.46.81.38/api/sketch-line?network=SITAMref=19style=padua ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] Corine Land Cover
Alberto Nogaro wrote: Perché inutile? La copertura di landuse in OSM qui in Lombardia mi sembra al massimo parziale e probabilmente anche selettiva Non è ancora stata importata (perlomeno non in maniera massiva) ma in Lombardia abbiamo l'autorizzazione per la carta dell'uso del suolo DUSAF [1], ora alla versione 2.1, che copre tutta la regione, ed è più recente e dettagliata della Corine Land Cover, e anche degli strati della CT10 (che oltretutto coprono la regione solo in parte) che sono già stati importati. [1] http://wiki.openstreetmap.org/wiki/Lombardia_ToDo#Carta_dei_Suoli_.28DUSAF.2 9 Sospettavo già una cosa del genere. Se abbiamo una fonte di dati più recente e precisa, ovviamente è meglio usare quella, ma se la copertura è limitata a Lombardia, conviene sempre prendere in considerazione Corine per il resto dell'Italia (infatti dell'Unione Europea, ma questo è un altro discorso). Ad esempio, potremmo importare i dati di Corine escludendo Lombardia ed eventualmente altre zone già mappate con qualità superiore. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappe dei nodi duplicati
M∡rtin Koppenhoefer wrote: 2010/11/22 groppo ottogrop...@gmail.com: Una volta mi è capitato ed ho messo noexit sul nodo finale. Purtroppo non ricordo dove fosse e non posso controllare se Inspector segnali ancora l'errore o meno. credo di aver letto che non vengono conteggati/segnalati questi col tag noexit ciao, Martin sì, per quanto ne sappia l'unico ragione d'essere di noexit è di segnalare a Inspector ed altri che il fatto che due node vicini non sono collegati è intenzionalmente e non per errore. Per i navigatori non serve tale tag: anche nella sua assenza si puo risalire al fatto che una strada è senza uscita o meno (presumendo sempre che i dati siano corretti). ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Corine Land Cover
M∡rtin Koppenhoefer wrote: 2010/11/21 Michael von Glasowmich...@vonglasow.com: Perché inutile? La copertura di landuse in OSM qui in Lombardia mi sembra al massimo parziale e probabilmente anche selettiva, se guardo verso ovest in Piemonte c'è ancora di meno. Se invece guardo qualche zona in Francia, sembra che ci sia di tutto. hai mai paragonato qualche foto areeo con il landcover francese? Ci sono degli errori e generalsazzioni che secondome non vanno bene. Gli errori potrebbero essere dovuti al fatto che i dati non sono attualissimi. Ammetto di non averlo mai verificato, però neanche le ortofoto alla nostra disposizione (PCN) sono attualissime: per la maggior parte dell'Italia sono del 2006, per alcune zone (Umbria e alcune altre, se non ricordo male) del 2008, quelle di Yahoo! sono del 2004 circa (almeno per la mia zona di Milano), quelle della provincia di Lodi non lo so. Sono quasi sicuro che Corine ha una buona quantità di informazioni utili per OSM. io sono di un parere contrario. Chi vuole usare corine con OSM già lo può fare, inutile che importiamo in OSM dei dati vecchi e grezzi. Col PCN si può ottenere di meglio. In teoria sì, in pratica per quanto ne abbia capito l'import di Corine si può automatizzare mentre le ortofoto si devono rintracciare a mano. Un import di Corine non significa che i dati poi dopo non si devono toccare mai più - anzi, una volta importati i dati diventano un nostro patrimonio e come tale bisogna verificarli e aggiornarli se sono sbagliati o se cambiano. Secondo me, possiamo tranquillamente importare ogni area che non è sovrapposta ad un'area già esistente in OSM che ha il tag landuse=. no, landuse e landcover sono 2 cose diverse. mi sono spiegato male, volevo dire che non vedo dei problemi se importiamo degli oggetti che non creano dei conflitti. Sarà utile taggare ogni area importata con l'ID che suppongo che abbia in Corine (es. corine:idU52878) per poter rintracciare cos'è già importato e cosa non lo è. non capisco perché: sopra hai scritto che non dovremmo importare zone/features dove si sovrapongono con features presenti in OSM, quindi l'ID non la vedo utile (perché questa paragone si dovrebbe sempre fare a precindere dell'ID). Non sto dicendo di non importare i features che creano dei conflitti - dicevo che quelli che non lo creano si possono importare senza grossi problemi; per i conflitti ci vuole una strategia e magari del lavoro a mano. In quanto all'ID: quando si fa un import a mano, conviene mantenere il legame tra l'oggetto originale e la sua rappresentazione in OSM per evitare degli import doppi (come successo nel caso di TIGER). Per i conflitti... possiamo importare anche quelle aree di Corine che sono in conflitto con dati esistenti e taggare tutti e due. -1 All'area importata mettiamo lo stesso tag che ho descritto sopra; per le aree in conflitto ci inventiamo un'altro tag che riporta l'oggetto di Corine con cui è in conflitto (es. corine:conflicting_ids�61107;8863610). quello lo puoi fare in locale, nel db di tutti non lo vedo. Se i dati di Corine sono meno affidabili di quelli già presenti in OSM, sarebbe infatti meglio saltare gli oggetti sovrapposti se la sovrapposizione eccede una certa soglia (dintorno a 90%). Se la sovrapposizione è inferiore, andrebbe controllato a mano. Conosco dei casi, ad esempio Sala Comacina [1], dove qualcuno sembra di aver iniziato di disegnare i boschi solo fino a un certo limite. [1] http://www.openstreetmap.org/?lat=45.96259lon=9.15549zoom=15layers=M ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Openlayer inserire marker con click
Salemme Guido wrote: Il problema è che volevo fare una cosa a livello locale e lo volevo inserire in un sito locale molto conosciuto. Potresti creare un permalink a OpenStreetBugs (esempio: [1] per Milano e dintorni). Nel peggior ipotesi fai un frame a parte in cui inserisci la pagina di OpenStreetBugs; studiandone il codice magari troverai un modo migliore per inserire solo la mappa. OT: sarebbe interessante integrare una cosa del genere nel wiki, ad esempio inserendo la mappa di OSB piuttosto che quella principale nella pagina wiki di una citta... quindi con zoom direttamente sulla zona di interesse e il più semplice possibile : inserisci marker e scrivi nota. Sostanzialmente OSB funziona così: clicchi sulla mappa, inserisci una breve descrizione dell'errore che hai trovato, un nome utente (se vuoi), e via. Nello stesso modo puoi aggiungere delle informazioni ovvero segnalare un'errore come risolto. Il sito funziona senza registrazione, perciò direi che è già fatto nel modo più semplice possibile. Il vantaggio sarebbe che, utilizzando il database di OpenStreetBugs, l'informazione sugli errori rimarrebbe concentrata in un singolo posto. Così per il mappatore che vuole sapere se e dove sono stati segnalati degli errori nella sua zone basta guardare OpenStreetBugs, dove vedrà sia i dati inserite direttamente attraverso OSB che quelli inseriti attraverso il portale locale che stai creando tu. ciao Michael [1] http://openstreetbugs.schokokeks.org/?zoom=13lat=45.47376lon=9.16625layers=B00T ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Corine Land Cover
alessio wrote: Incuriosito dagli import massivi che stanno avvenendo in Romania ho dato un'occhiata alle pagine nel wiki create per questo proposito [¹] scoprendo che l' Unione Europea , attraverso al EEA[²] mette a disposizione del pubblico i dati riguardanti il land cover (ma non solo) di tutti i paesi dell'Unione. Inutile pensare ad import massivi per l'Italia Perché inutile? La copertura di landuse in OSM qui in Lombardia mi sembra al massimo parziale e probabilmente anche selettiva, se guardo verso ovest in Piemonte c'è ancora di meno. Se invece guardo qualche zona in Francia, sembra che ci sia di tutto. Sono quasi sicuro che Corine ha una buona quantità di informazioni utili per OSM. Bisogna però pensare a come gestire i conflitti, voul dire le zone già sorvegliate. La pagina Wiki che ci hai segnalato parla appunto di questo e degli approcci per gestire i conflitti. Secondo me, possiamo tranquillamente importare ogni area che non è sovrapposta ad un'area già esistente in OSM che ha il tag landuse=*. Sarà utile taggare ogni area importata con l'ID che suppongo che abbia in Corine (es. corine:id=5552878) per poter rintracciare cos'è già importato e cosa non lo è. Per i conflitti... possiamo importare anche quelle aree di Corine che sono in conflitto con dati esistenti e taggare tutti e due. All'area importata mettiamo lo stesso tag che ho descritto sopra; per le aree in conflitto ci inventiamo un'altro tag che riporta l'oggetto di Corine con cui è in conflitto (es. corine:conflicting_ids=8061107;8863610). Nota bene che un'area in JOSM può essere in conflitto con più di un'area in Corine (e vice versa); cosi questo tag sarebbe un'elenco di ID piuttosto che uno singolo. Delle aree in conflitto, tagghiamo una come landuse=* e l'altro con un tag da inventarci che non viene renderizzato (es. conflict:landuse=*). Abbiamo due possibilità: * Lasciare i landuse in OSM come sono e taggare le aree importate con conflict:landuse=* se sono in conflitto (le altre aree importate saranno landuse=* in ogni caso) * Taggare tutte le are importate con landuse=*e cambiare da landuse=* a conflict:landuse=* i tag di tutte le aree già esistenti e in conflitto con Corine. Questo è l'unico imbarazzo della scelta che ci sarebbe: i creatori di Corine sicuramente non saranno gli ultimi ad arrivare; ma anche OSM produce dei dati di qualità. Per le aree già coperte da OSM bisognerà in ogni caso controllare i dati e risolvere i conflitti. Non consiglierei di eliminare dei dati già in OSM: può sempre essere che noi abbiamo qualcosa che non è ancora in Corine, che i nostri dati siano più aggiornati ovvero più precisi. Ove ci sono i conflitti, vanno risolti esaminando ogni caso. ciao Michael [¹] http://wiki.openstreetmap.org/wiki/Romania_CLC_Import [²] http://www.eea.europa.eu/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] controllo del contributo degli utenti
Guardate anche [1] per sapere come procedere con i contributi ciao Michael [1] http://wiki.openstreetmap.org/wiki/FAQ#I_think_someone.27s_been_entering_copyrighted_data_-_how_do_we_deal_with_that.3F Giacomo Boschi wrote: Il 19/11/2010 22:43, Andrea Ticci ha scritto: Molti dati, tra l’ altro, risultano inaccurati e vanno malamente a sovrapporsi a tracce esistenti ottenuti da tracce GPS verificate accuratamente anche con ortofoto. Inoltre sempre nella zona dove opero, lo stesso ha inserito senza alcun criterio comprensibile moltissime aree “taggate” come (Natural; wood) rendendo estremamente affollata e difficile la mappatura della zona (nessun uso di multi-poligoni). Potresti postare il link ad un paio di esempi di questi pasticci? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Inserimento nome Vie
On 01/-10/-28163 08:59 PM, carlo...@teletu.it wrote: Ciao a tutti da qualche mese sto mappando strade e sentieri e per quanto possibile inserisco sempre il tag name: ; nelle indicazioni che ho trovato su wiki è indicato di mettere il nome completo della strada precedendolo da Via, Viale Vicolo etc.. Questa sera ho provato con MapSource della Garmin ,in cui ho installato le mappe prese da openmtbmap la funzione TROVA ma questa funziona solo per quelle strade il cui nome è stato inserito senza Via... Con altri programmi di gestione mappe (tra l'altro io non ne conosco) come funziona ? se non ricordo male, Navit fa un substring search, cioè cercando rossi troveresti sia Via Rossi che Via Mario Rossi. Questo è però interamente a scelta del navigatore ovvero dei suoi programmatori. Prima di scoprire OSM avevo un navigatore di Falk, classico esempio per come NON programmare un navigatore: bisognava inserire il nome intero o almeno l'inizio; per trovare John Doe Street bisognava mettere proprio John..., se mettevi solo Doe non ti risultava niente. Molto comodo in Italia, dove tre quarti delle strade iniziano per Via. Quando si digitava il nome, cominciava a cercare quando non si digitava un'altra lettera per 1 o 2 secondi... se digitavo lentamente, crashava perché no se la cavava più con il numero di strade a Milano che iniziano per Via... Insomma, direi che un buon programma fa semplicemente un substring search, già perché spesso ci sono vari modi per scrivere il nome della strada (Via Mario Rossi, Via Rossi Mario, Via Rossi, Via privata Rossi...), e tanti utenti non sono sicuri se la strada si chiama Via o magari Viale... ma dipende sempre di quale estremità della sua spina dorsale ha impiegato il programmatore. In ogni caso è corretto taggare le strade come Via Mario Rossi - guarda le strade che hai inserito tu sulla mappa, poi le altre, e vedrai che so OSM ti risulterà il nome come da te digitato, e che anche le altri mettono il nome intero delle strade. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-transit] What's going on with Öpnvkarte ?
On 11/12/2010 08:45 PM, Michael von Glasow wrote: Hello list, For those of you who don't already know me from other lists I participate in, my name is Michael and, among others, I map public transportation in Milan. Up to now I have relied on Öpnvkarte (aka openbusmap.org) for representing bus, tram and other routes. However, as some of you may have noticed, the site appears somewhat deserted - the last update is reportedly from early September (without specifying a date; the site used to be updated multiple times a week with a precise date on the main page) and tiles in the higher zoom levels are broken. Does anybody know what's going on? I sincerely hope the project has not been abandoned and the outage is only temporary... up to now, this has been the definitive site for public transportation mapping, and I'd be really sad to see it go... Michael In the meantime, I have found a posting by Melchior Moos, the maintainer of Öpnvkarte, to talk-de (in German). Basically, the load has gotten too much for his server to handle, and at the moment he does not have the time to fix it. So we'll have to wait and see... ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-it] cambio licenza - mappa colorata
On 01/-10/-28163 08:59 PM, Fabio Alessandro Locati wrote: Penso che per 'entrambe' tu intenda sia l'ODbL sia il PD. Se non accetti l'ODbL, i dati da te inseriti verranno persi (quindi hai fatto bene ad accettarla, imho), 'accettare' il PD, in realtà è irrilevante, perchè un informazione raccolta solo a fini statistici ;) Secondo me è più di solo un'informazione statistica: l'utente che accetta il PD dà il consenso all'utilizzo libero dei suoi contributi - anche in forma mista con dati proprietari e facendo parte di un prodotto proprietario - insomma ha un effetto legale, anche se OSM a questo punto non se ne avvale. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cambio licenza - mappa colorata
On 01/-10/-28163 08:59 PM, M∡rtin Koppenhoefer wrote: 2010/11/12 Michael von Glasowmich...@vonglasow.com: Direi che hanno usato la planet.osm di +/- 3 settimane fa. Vedo degli aggiornamenti che avevo fatto circa in quel periodo, quelli dell'altro ieri invece no. hanno usato la history completa, quindi non un semplice planet. ciao, Martin ok, devo precisare: usano lo storico fino a un punto di tempo +/-3 settimane fa. I miei aggiornamenti del 10 sempre non ci sono... i miei contributi di prima invece già sono in verde. Sembra che l'accettanza dell'ODBL si aggiorna più spesso rispetto allo storico. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cambio licenza - mappa colorata
On 01/-10/-28163 08:59 PM, Luigi Toscano wrote: alberto bonati wrote: Il 12/11/2010 21.59, Fabio Alessandro Locati ha scritto: Infatti il vero problema sono gli utenti che hanno smesso di editare... Appunto... Come in tutte le cose, c'è sempre gente che partecipa e poi lascia perdere. Contattati, magari qualcuno accetta il cambio licenza, ma ce ne saranno altri che non si prenderanno nemmeno la briga di rispondere. Se ho capito bene verranno persi oggetti creati da utenti che non hanno accettato, anche se successivamente modificati da altri che hanno accettato il cambio di licenza... E' una cosa assurda, anche capendo tutte le ragioni che vi stanno dietro. Significa buttare all' aria una montagna di lavoro... Non credo faccia un gran bene ad OSM una cosa del genere. Il punto è che, senza questo cambiamento, dopo sarebbe peggio (per gli informatici: l'esperienza del kernel Linux - che di fatto non potrà mai essere rilicenziato sotto una licenza diversa dalla GPLv2 - dovrebbe insegnare qualcosa). Purtroppo è stato necessario del tempo per rendersi conto del problema ed arrivare a questo punto; ma grazie a queste modifiche una tantum, problemi di questo tipo dovrebbero essere definitivamente risolti . Ciao Mi sto chiedendo se le due licenze sono compatibili: L'ODBL si riferisce solo alla database intera ovvero estratti sostanziali di dati, ma non al contenuto. La CC invece si riferisce solo allo contenuto. IANAL, ma per quanto ne abbia capito, non sono in conflitto. Perciò dovrebbe essere possibile anche dopo il cambio licenza produrre una database che contiene sia le modifiche vecchie (di cui alcuni solo sotto la CC, altre a scelta sotto CC o OBDL) che quelle nuove (che sarebbero esclusivamente sotto l'ODBL). Tale database sarebbe sotto l'ODBL; i contenuti sarebbero sotto la CC. Chiunque la usa dovrebbe perció soddisfare i termini di tutte e due licenze. Ovviamente non risolverebbe i problemi che crea la licenza CC (se prendo la mappa e la metto sulla mia homepage, devo licenziare la homepage sotto la CC?) ma permetterebbe di usare tutti i dati esistenti. Poi sarebbe possibile estendere l'API, permettendo di scegliere la licenza (ODBL, CC ovvero ODBL+CC) e ritornare solo i dati che corrispondono alla scelta dell'utente. ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cambio licenza - mappa colorata
On 01/-10/-28163 08:59 PM, G Zamboni wrote: Il 12/11/2010 11.00, Simone Saviolo ha scritto: Mi sembra che il planet usato non sia molto recente, però. Alcune strade non sono colorate né in rosso né in giallo né in verde. Inoltre, se non sbaglio, l'analisi fatta riguarda solo le highway, giusto? Infatti riguarda solo le ways. Se vedi delle ways non colorate prova ad aumentare l'ingrandimento. Se inquadri un'area ampia ti evidenzia solo le strade principali. Direi che hanno usato la planet.osm di +/- 3 settimane fa. Vedo degli aggiornamenti che avevo fatto circa in quel periodo, quelli dell'altro ieri invece no. Il colore dei way viene aggiornato più spesso (i miei contributi sono già in verde), ma solo per i tiles non renderizzati già prima. I tiles in cache non vengono aggiornati subito, però potete guardare un singolo tile e poi fare i soliti scherzetti con tile url/status e /dirty. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cambio licenza - mappa colorata
On 01/-10/-28163 08:59 PM, Simone Cortesi wrote: 2010/11/12 Alessio Zanolnar...@infinito.it: sto controllando un po' le zone mappate da me con la mappa segnalata e ho moltissime strade modificate da Paolo Molaro credo con qualche script per sistemare le maiuscole se ricordo bene. Sinceramente mi scoccia un bel po' perdere tutte le mie modifiche successive solo perchè è stata modificata una maiuscola o simili. Non si potrà fare il revert SOLO del nome, senza andare ad intaccare tutto il resto? stessa cosa successa a me quando importai anni fa i confini di tutti i comuni italiani, furono modificate da un bot le proprietà di alcune relation. Per quanto ne abbia capito, quando avverrà il switch-off, dagli oggetti gialli conserveranno tutto fino alla prima modifica di un'utente che non ha accettato l'ODBL (esclusa quest'ultima modifica stessa). Per esempio: Tu hai inserito una way e l'hai taggata name=via pippo. Poi un bot lo ha cambiato in Via Pippo Tu hai accettato l'ODBL, l'utente del bot invece no. Viene conservata la tua modifica originale, ma quella del bot si perde. Cioè, nella versione ODBL risulterà name=via pippo. Altro esempio, più complesso: Utente odbl1 inserisce una way e la tagga highway=unclassified;name=Via Pinco. Utente odbl2 cambia un tag a highway=tertiary. Utente cc1 aggiunge oneway=yes. Utente odbl3 aggiunge maxspeed=60. Gi utenti odbl1, odbl2 e odbl3 accettano, cc1 non accetta. Vengono conservate le modifiche di odbl1 e odbl2, dato che tutte queste informazioni sono sotto la ODBL. La modifica di cc1 si perde perché non e sotto la ODBL. Per quanto ne abbia capito viene perso anche la modifica di odbl3 perché è avvenuta dopo una modifica che non è sotto l'ODBL. In teoria si potrebbe conservare la modifica di odbl3, però posso immaginarmi dei casi in cui una modifica dipende da un'altra fatta in precedenza; persa quest'ulteriore, anche quella apportata dopo diventa inutile o proprio sbagliata. Purtroppo non si vede chi ha già accettato l'ODBL e chi no - altrimenti potremmo guardare le way gialle nelle nostre zone insieme al loro storico, individuarne gli utenti che non hanno accettato l'ODBL e contattarli. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Fwd: [OSM-talk] license change map
Ho appena guardato la mia zona a Milano e scoperto che anche i miei edit sono in rosso... ho accettato subito i termini di contribuzione. Infatti non ho ancora deciso se sono pro o contra il cambio all'ODBL; per il momento il mio unico argomento contra l'ODBL è che dopo il passaggio dovremmo bloccare/eliminare i dati contribuiti di chi non ha consentito il cambio. Accettare il termini *non* è un voto per il passaggio all'ODBL stessa: si da solo il consenso all'utilizzo dei dati contribuiti sia sotto la licenza CC che sotto l'ODBL ovvero un'altra licenza libera e aperta dopo un voto di 2/3 dei contributori attivi. Credo che la mia scelta in quanto alla licenza dipenderà della dimensione di dati che rimarrebbe alla nostra disposizione dopo il passaggio. In ogni caso non voglio bloccare il progresso di OpenStreetMap e perciò ho dato il consenso di utilizzare i miei dati sotto i termini dell'ODBL. Ho iniziato a contribuire perché volevo una mappa libera del mondo, della mia zona e delle zone in cui un giorno forse mi reco, e voglio dare il mio contributo. Spero di aver convinto alcuni di voi di accettare i termini - sarebbe un peccato perdere dei dati, o vedere OSM dividersi in due (la frazione pro ODBL e quella contra ODBL), perché diminuirebbe effettivamente il numero di contributori. ciao Michael On 01/-10/-28163 08:59 PM, Davide Gobbi wrote: Pordenone è messa anche molto peggio http://osm.informatik.uni-leipzig.de/map/?zoom=14lat=45.96438lon=12.66477layers=B0 http://osm.informatik.uni-leipzig.de/map/?zoom=14lat=45.96438lon=12.66477layers=B0 Credo che non farò alcuna modifica in città fino a passaggio avvenuto. Ciao Davide *Da:*talk-it-boun...@openstreetmap.org [mailto:talk-it-boun...@openstreetmap.org] *Per conto di *G Zamboni *Inviato:* giovedì 11 novembre 2010 21.19 *A:* talk-it@openstreetmap.org *Oggetto:* Re: [Talk-it] Fwd: [OSM-talk] license change map Il 11/11/2010 20.14, iiizio iiizio ha scritto: On Thu, Nov 11, 2010 at 6:40 PM, Simone Cortesisim...@cortesi.com wrote: mappa delle way di chi ha aderito alla ODBL... http://osm.informatik.uni-leipzig.de/map/ Bella, ma vedo troppo giallo per i miei gusti. Beh, allora Padova non ti tirerà su di morale... http://osm.informatik.uni-leipzig.de/map/?zoom=13lat=45.39409lon=11.93298layers=B0 http://osm.informatik.uni-leipzig.de/map/?zoom=13lat=45.39409lon=11.93298layers=B0 Ciao Giuliano iiizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnalazione tracce GPS
On 01/-10/-28163 08:59 PM, Federico Cozzi wrote: 2010/11/7 Alessio Zanolnar...@infinito.it: Su questo sito sono disponibili un sacco di tracce GPS scaricabili: http://www.paolaegino.it/MTB/gps.htm In fondo alla pagina c'è un bel All Rights Reserved Tempo fa anch'io andavo alla ricerca di tracce (MTB, sentieri ecc.) per importare il più possibile, ma poi mi sono accorto che una traccia GPS prodotta da un altro (soprattutto se in MTB) è poco utile: non si capisce se è path, track, unclassified ecc. Siccome abbiamo a disposizione le ortofoto, potresti caricare sia le tracce che le ortofoto, e poi ricalcare *dalle sole ortofoto*. Le ortofoto sono spesso più precise delle tracce GPS e a volte si riesce a capire il tipo di highway. Ciao, Federico Concordo che la precisione delle ortofoto è spesso (secondo me, di solito) superiore a quella del GPS, particolarmente in montagna. Però alcune cose non si vedono bene dalle ortofoto - strade nascoste tra degli alberi, cancelli etc. In tali casi una traccia GPS può ridurre i dubbi: dove passano diverse tracce, vi è probabilmente un percorso accessibile al pubblico. Ricordiamoci anche che le ortofoto sono disponibili solo per l'Italia (i spagnoli hanno un servizio simile). Chi si spinge oltre le confini dello stato in tanti casi non ha delle ortofoto a disposizione. E' vero che non si vede tutto, perciò è sconsigliato fidarsi anche dell'insieme di tracce + ortofoto. Perciò io, quando faccio dell'armchair mapping, taggo come highway=road tutto quello che non conosco bene, e di solito lo faccio solo prima di andarci per verificare la situazione sul posto. Ovviamente, bisogna sempre stare attenti alla licenza. Nel caso di Paola e Gino, si potrebbe sempre chiedere se loro permettono l'uso dei loro dati per i scopi di OSM. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento OPVN-Karte e OSMtransport
On 01/-10/-28163 08:59 PM, Davide Agati wrote: Ciao, Qualcuno sa con che frequenza vengono aggiornati gli strumenti come OPVN Karte e OSMTransport? Almeno di quest'ultimo ho letto che We update the database every morning from data made available by Geofabrik ma oramai sono alcune settimane che ho mappato le prime linee del trasporto pubblico di Torino[1] e non ho visto progressi sulla carta... Ho avuto lo spesso problema anche io. Ho inserito alcune linee a Bologna ma ancora nulla. Qualche settimana fa mi era sembrato di vedere, su OPVN Karte, un bottone in alto a destra per aggiornare la mappa ma adesso non c'è più. Ciao ciao, infatti, sembra che il bottone ich hab hier was geändert, tiles neu rendern sia stato tolto dopo poco. Ormai dovreste vedere una notizia sotto la mappa che l'ultimo aggiormento sia avvenuto verso inizio settembre e al momento non ci siano degli aggiornamenti. O il sito ha dei problemi, o Melchior sta preparando dei grossi cambiamenti (speriamo), o non ha tempo per occuparsi del sito... ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] impostazioni wmsplugin funzionanti
On 01/-10/-28163 08:59 PM, Simone Cortesi wrote: 2010/10/7 Stefano Tampieristefano.tampi...@gmail.com: Sapete che dopo quasi un mese e diverse email spedite non mi hanno ancora sbannato l'IP dell'ufficio che purtroppo è fisso ? Le altre volte mi rispondevano in giornata. mi piacerebbe mandare una mail al PCN mettendo in evidenza quali sono state le zona dove è stato possibile lavorare a migliorare la copertura osm grazie alla loro autorizzazione. avete consigli sulle areee osm meritevoli di essere segnalate? Mi viene in mente il comune di Carrù (CN) [1], che prima del PCN era composta dalle sole strade principali di scorrimento. Ci sono stato due settimane fa, il PCN mi ha aiutato a mappare già in anticipo la maggior parte delle strade. Così ero in grado di coprire la maggior parte del centro seguendo solo alcune strade principali. Tutto ciò non sarebbe stato possibile senza il materiale del PCN, dato che nelle vie strette del centro la qualità del GPS non e per niente soddisfacente. Michael [1] http://www.openstreetmap.org/?lat=44.48032lon=7.87247zoom=15layers=M ___ 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
On 01/-10/-28163 08:59 PM, Maurizio Daniele wrote:
Mentre sto mappando un po' di linee di trasporto pubblico ne approfitto
per sistemare la configurazione di alcune strade e viali, aggiungendo i
dettagli.
Ora, vorrei sapere che ne pensate di alcune situazioni:
Per i grandi viali, a due o più carreggiate con sede tramviaria
separata, il problema non si pone. Mappo ogni carreggiata con una way e
la sede tramviaria con una coppia di binari.
Anche nel caso in cui la coppia di binari rappresenti una carreggiata
asfaltata (perché ad esempio è condivisa con delle linee bus), magari
riservata al trasporto pubblico, mi comporto allo stesso modo.
Per le stradine più piccole che inglobino i binari, esiste la
possibilità di aggiungere un banale railway=tram ai tag highway=*, ma
questo mi lascia un po' di disappunto perché tendenzialmente mi piace
mappare la coppia di binari (che è differente da un binario solo
utilizzabile in doppio senso), per cui solitamente mi piacerebbe
lasciare il caso {highway=unclassifield,railway=tram} esclusivamente
alle strade a senso unico con binari tramviari non separati.
A questo punto mi sorge però il problema di come taggare una strada a
singola carreggiata, doppio senso, con binari tramviari in entrambi i
sensi (esempio [1]), senza o con corsia riservata (esempio [2]).
Caso analogo, una via a singola carreggiata, doppio senso, con corsia
riservata BUS/Tram doppio senso ma posta in centro alla carreggiata
[3]...
La cosa più banale che mi possa venire in mente è duplicare le way, ma
ho paura così di rappresentare una semplice via come un enorme viale...
Anche il tag lanes=N non mi risolve il problema.
Che ne dite?
[1] http://tinyurl.com/38ypdq5
[2] http://tinyurl.com/23myon6
[3] http://tinyurl.com/2vevfz2
Ciao Maurizio,
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.
Due o più binari paralleli possono essere rappresentati da una singola way.
Le strade vanno taggate come due way separate quando vi sono due (o più)
carreggiate fisicamente separate. in tale modo da non essere facilmente
attraversabile con un veicolo normale; se vi è solo la linea di
mezzeria, è una singola way.
Allora...
Esempio [1]: metterei una way taggata highway=*;oneway=no
(quest'ulteriore non è strettamente necessario), poi un'altra taggata
railway=tram usando gli stessi punti.
Esempio [3]: per ogni corsia aperta al traffico regolare metterei una
way highway=*;oneway=yes, tra questi due un'altra way taggata
highway=*;oneway=no;access=no;psv=designated (ovvero psv=yes), poi
un'altra way sovrapposta utilizzando railway=tram.
Esempio [2]: Dipende... se l'unica separazione tra le corsie riservate e
le altre e una linea, vedi esempio [1]. Altrimenti, vedi [2].
ciao
Michael
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Trasporto pubblico: linea con vari percorsi appartenenti a differenti network
On 01/-10/-28163 08:59 PM, Maurizio wrote: Il 05 ottobre 2010 10:51, Tiziano D'Angelotiziano.dang...@gmail.com ha scritto: ciao Maurizio. ecco, alla fine tutti si scontrano con gli stessi problemi... ho inserito nel DB sotto il medesimo network=S Mobilità tutte le linee anche con stesso ref, differenziandole nel tag name (ad es. 10 Serale Ponte di Brenta-Sarmeola - 12 Festivo Ponte di Brenta-Selvazzano) e nelle opening_hours come hai fatto in soluzione 1. Credo anch'io che opterò per mantenere questa visione delle cose: un unico network con openinghours differenti, dopodiché magari si farà la proposta affinché i tool (OPVNKarte etc...) possano gestire gli orari di esercizio e linee che appartengono a differenti network, in modo da distinguere in un modo o nell'altro i network feriali o festivi. +1, il network rimane sempre lo stesso, perciò lo taggherei come uno singolo. Concordo anche per gli orari. Anche il nome può andare bene - di questo però non sono dal tutto sicuro, dato che non ho visto ancora nessun renderizzatore che utilizza quel tag, così al momento si potrebbe in teoria mettere di tutto e di più un questo tag e non si vedrebbe mai la differenza. Al massimo serve per individuare le relazioni in JOSM; per tale motivo ho proposto lo schema ref from - to per Milano. La soluzione 3 può essere corretta, ma adottandola dovrei giustamente inserire anche le relazioni delle linee che non cambiano percorso da feriale a festivo (tipo la linea 3, 11, 22, etc), ma a quel punto dovrei inserire un network =APS Mobilità; APS Mobilità Serale che non so quanto sia digerito/accettato da OSM. Beh... qualche esperimento mi dice che una scritta come quella sopra che, teoricamente, indica due network, viene presa come un unico network dal nome APS Mobilità; APS Mobilità Serale. Almeno da sketch-line, che però riporta gli orari di esercizio. In teoria i renderizzatori dovrebbero interpretarlo come due network: Pensate a due aree metropolitane, ognuna con il suo network, ed una linea che collega le due aree ed appartiene infatti a tutti e due network - ad esempio, su questa linea si potrebbero utilizzare dei biglietti di qualsiasi dei due network. Però, come già detto, questo modo di taggare va riservato ai casi in cui vi siano davvero due network diversi. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Cantina Vini - distilleria - maneggio di cavalli
On 01/-10/-28163 08:59 PM, Diego Guidotti - Aedit s.r.l. wrote: 2010/10/6 Luca Delucchi lucadel...@gmail.com mailto:lucadel...@gmail.com ok, allora il problema si estende... perchè un conto è un shop (negozio per la vendita) un conto è la produzione composta da: vigneti (landuse=vinegard ed è risolto) ma i locali di produzione non sono di certo un negozio. a sto punto? Distinguiamo le cantine (dove si produce il vino) dalle le enoteche (dove si vende il vino) Per la cantine proporrei man_made=winery (ed aggiungerei di straforo anche man_made=olive_mill per i frantoi). Questo indipendentemente dal fatto che venga fatta o meno la vendita diretta del vino (nel caso si può aggiungere shop=wine). man_made=works è un po troppo generale penso sia proponibile una cosa più specifica. Il problema è che andrebbero poi raccordati i vari shop=winery (probabili conatine) e tourism=winery. Ciao, Diego Va bene, mi sto però chiedendo come taggare in modo corretto un'azienda vitivinicola che offre delle degustazioni e la vendita di vini di propria produzione, in modo da distinguere tali aziende dalle enoteche. Secondo me sono due cose diverse, dato che le enoteche vendono dei vini da diverse regioni e produttori, mentre le aziende vitivinicole vendono esclusivamente quello che producono loro. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] a qualcuno serve un plugin per JOSM?
On 01/-10/-28163 08:59 PM, M∡rtin Koppenhoefer wrote: non so se hanno già implementato che il plugin per la georeferenziazione delle foto scrive gli tag dentro alle foto, ma sarebbe una cosa commoda (e poco complicato probabilmente troppo poco). I dettagli sarebbe di non cambiare la data di modifica o alterare altri aspetti della foto (ancora probabilmente triviale). esiste già, il plugin si chiama photo_geotagging ed è selezionabile in JOSM. Se scegli di conservare le foto originali (modificandone l'estensione da JPG a JPG_), funziona benissimo. Una volta georeferenziate le foto, scegli l'apposito commando dal menu, confermi le immagini da modificare, e vai. E' diventata una mia procedura standard per non dover mantenermi la relazione tra foto e tracciate, compreso il drift degli orologi. ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Cellulari Android per OSM
On 01/-10/-28163 08:59 PM, ale_z...@libero.it wrote: Messaggio originale Da: spacexplo...@gmail.com Data: 30/09/2010 19.50 A: openstreetmap list - italianotalk-it@openstreetmap.org Ogg: Re: [Talk-it] Cellulari Android per OSM Ps Il G1 è *troppo* lento con Android 2.2 per usarlo comodamente oggi, ed essendo in uscita il G2 non ha senso comprarlo ma scartando Motorola sia HTC che Samsung hanno molti buoni modelli ___ Grazie per le info, ma dopo aver passato un paio di giorni a leggere caratteristiche penso che aspetterò un mese e prenderò il prossimo LG Optimus one con 2.2 e 512Mb di ram ad un prezzo che dovrebbe essere intorno ai 230€ La tastiera fisica non mi interessa molto visto che lo userei solo per telefonare e poco più, oltre ovviamente per OSM, non sono un patito di SMS nè social network. Lo voglio con la possibilità di connettere un GPS esterno perchè anche se l'interno funzionerà bene non penso possa competere col BT747+ Quindi il pericolo che debba arrendermi a M$ sembra scampato, resta il fatto che non riuscirò ad usare NTRIP (peccato peccato). Resto comunque in ascolto per consigli o notizie riguardanti NTRIPclient Alessandro In quanto a J2ME/J2SE: Android usa un suo proprio dialetto di Java, quindi non è possibile eseguire delle applicazioni scritte per altri cellulari senza modificarle. Esiste però un NDK (Native Development Kit), che permette di eseguire codice scritto in C. Ad esempio, pur essendo scritto in C, Navit è disponibile per Android. Vi sono due modelli da aggiungere: primo, il Geeksphone One [0]: dicono che sia il primo cellulare con Android che è aperto, nel senso che il rooting è già fatto in fabbrica, e vi sono disponibili delle immagini di firmware dalla community. Dovrebbe essere anche possibile hackerarlo senza troppi ostacoli. Ha una tastiera fisica, una camera integrata e un display WQVGA (credo 240×400). secondo, anche per il Freerunner [1] esiste una versione di Android. Questa l'ho già hackerato, quindi è assolutamente possibile. Il problema è però che il hardware del Freerunner non è stata creata per Android e non è 100% stabile. A volte si perdono delle chiamate o non si possono accettare. Non ha una camera. Una cosa che mi piace tanto è la risoluzione del display, che arriva a 480×640. Tutti e due costano circa € 300. Ho attualmente il Freerunner, che mi ha fatto diventare un tifo di Android, voglio però tenermi la libertà di hackerarlo come mi pare. Perciò il mio prossimo telefono probabilmente sarà il Geeksphone One. Il display di alta risoluzione mi mancherà, spero il prossimo modello del Geeksphone sia meglio in questo rispetto... [0] http://www.geeksphone.com [1] http://wiki.openmoko.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] a qualcuno serve un plugin per JOSM?
On 01/-10/-28163 08:59 PM, Federico Cozzi wrote: 2010/9/30 Andrea P.bigsto...@hotmail.it: purtroppo pero', sara' che sono un mapper rozzo, ma non mi viene in mente niente. avete suggerimenti? ...naturalmente non prometto nulla sulla riuscita del progetto. Siccome noi italiani abbiamo le ortofoto del PCN, che nessun altro ha con tale risoluzione, forse potremmo sentire il bisogno di qualche plugin mirato alle ortofoto. Un'idea diversa che mi è venuta in mente questi giorni: Quando creo delle tracciate GPS in una zona parzialmente coperta, voglio risparmarmi il lavoraccio di analizzare *tutta* la tracciata per individuare i tratti di via mancanti. Sarebbe bello se potessi confrontare la mia tracciata con la mappa - questo potrebbe essere un'idea per un plugin. Il workflow sarebbe quello: - Caricare le tracciate - Scaricare le relative aree da OSM - Individuare i tratti delle tracciate che seguono delle way già esistenti (con snap to roads e bella compagnia, come fanno anche i navigatori) e quelle che sono (possibilmente) delle way nuove - Fare l'utente revisionare i segmenti che rappresentano delle way mancanti (es. attraverso due pulsanti segmento precedente e segmento prossimo), permettendogli di aggiungere i tratti (a mano) ovvero: - Creare automaticamente le way nuove (con il solo tag highway=road), semplificando i percorsi del GPS (forse in modo adattivo, dato che a velocità bassa ci vuole un po' di più in termini di correzione; forse anche usando delle eventuale tracciate già caricate su OSM) - Fare l'utente revisionare in modo guidato e interattivo le way create (possibilmente con due pulsanti seleziona way precedente e selezione way prossima) - importantissimo per correggere delle grosse inesattezze create dal GPS Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Milano: metropolitane future
On 01/-10/-28163 08:59 PM, Elena of Valhalla wrote: On 8/30/10, Simone Saviolosimone.savi...@gmail.com wrote: [...] Se davvero la M4 non è taggata in modo da capire che esiste solo un progetto su carta, allora sì, è un problema. Le stazioni sono taggate esattamente come se fossero stazioni esistenti, ed e` un grosso problema. La way e` taggata come se fosse un cantiere, il che non e` accurato, ma meno propenso a causare errori gravi In quanto all'acuratezza di construction, la pagina wiki [0] descrive anche railway=proposed e railway=planned, senza specificare però il loro significato in dettaglio. Allora propongo di taggare le stazioni come railway=xyz; xyz=station, sostituendo xyz con proposed, planned o construction a secondo delle circostanze. Per le stazioni non è ufficiale (secondo il wiki vale solo per le way ed aree), ma andrebbe introdotto secondo me perché la necessità è la stessa. [...] Secondo me un punto di equilibrio possibile sarebbe segnare la metro nel momento in cui sia effettivamente in costruzione e non prima. +1. Fermo restando quello che ho detto sopra, la cosa più semplice (soprattutto visto che siamo ancora in fase di completamento della mappa, e non di manutenzione) è mettere solo ciò che esiste. Una metro esiste; un cantiere esiste; un progetto esiste anche quello, ma magari cambia (il cantiere e la metro una volta che ci sono non vengono annullati con un colpo di penna). quando un progetto viene considerato esistente? di solito per le opere di questo tipo si vedono proporre ed approvare almeno una dozzina di progetti, tutti diversi e nel corso di decine di anni, prima di veder aprire qualche cantiere Hai ragione, questo può essere difficile in realtà. Al più tardi è quando è stato lanciato (o solo approvato) il progetto di construzione. Dal punto di vista concettuale direi: quando è deciso in modo definitivo che la construzione avverrà, in modo che da qui in poi si parli solo del quando (e forse del come), ma non più del sì o no. €0.02 Michael [0] http://wiki.openstreetmap.org/wiki/Key:railway ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Milano: metropolitane future
On 01/-10/-28163 08:59 PM, Federico Cozzi wrote: 2010/8/28 Carlo Stembergercarlo.stember...@gmail.com: Solo un esempio col quale mi sono scontrato poche settimane fa: l'atlante stradale d'Italia del TCI finito di stampare nell'agosto 2003 segna come in costruzione o in progetto la Vicenza-Rovigo. Di quella strada tutt'oggi non c'è niente. Qual è l'utilità di una tale indicazione, per il fruitore dell'atlante stradale del TCI? Probabilmente il TCI sperava che venisse davvero costruito, e che sarebbe stato costruito prima del prossimo aggiornamento dell'atlante. Purtroppo (non è colpa del TCI) quell'ottimismo era eccessivo. Noi con OSM possiamo aggiornare in 5 minuti, non vedo il motivo di prevedere un'opera che - se va tutto bene - sarà finita nel 2014. E non è ancora iniziata! Ciao, Federico Aggiornare i dati sul server e poi visualizzarli in Mapnik magari ci mette 5 minuti, ma questo è solo una singola applicazione di OSM. Altre applicazioni ci mettono un paio di giorni per fornire le informazioni aggiornate, e questo va solo per le cose accessibili in rete. Se invece mi scarico delle mappe per Navit sul mio palmare, o se mi stampo una mappa su carta, è un altro discorso - queste cose non le voglio dover aggiornare ogni giorno. Un'altro discorso è sempre quello di conservare le conoscenze: se già sappiamo dove un giorno passerà la metropolitana, perché non aggiungerlo? Ovviamente deve essere identificabile come progettata (e non ancora utilizzabile), e solo per i progetti che verranno davvero realizzati e per i quali è già definitivo il percorso. Concordo che è inutile mappare le linee progettate se non è ancora deciso con certezza quale su cinque proposte diverse viene realizzata. E' anche vero che un progetto può essere abbandonato, anche dopodiché sono già fatti dei lavori. (Un'esempio era la A98 tedesca, che sarebbe passata dal Lago di Costanza fino a Rosenheim, dove avrebbe raggiunta l'autostrada a Salisburgo. Sono stati realizzati solo alcuni tratti brevi, esiste però una cavalcavia sull'autostrada Monaco-Garmisch, che in questo punto avrebbe incrociato l'autostrada nuova, ma il progetto è stato abbandonadi negli anni 80.) In questo caso si può sempre cancellare tutto quello che non è mai stato costruito. A proposito dell'esattezza dei percorsi: la verificabilità è sempre un problema per le strutture sotterranee come una metropolitana, già per quelle esistenti il percorso spesso è poco più di una seria di linee dritte da una fermata all'altra. Inserire le linee progettate avrebbe il vantaggio che così l'esattezza del percorso si potrebbe aumentare gradualmente, mappando continuamente il lavoro in corso. Ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Re: cinafonino con gps e android
On 01/-10/-28163 08:59 PM, Stefano Droghetti wrote: anche i modelli di cui il produttore/rivenditore cinese dichiara Android come s.o. in realtà hanno un simil-clone-quasi-compatibile che sembra android ma non lo è Esatto! È proprio questo il problema, Io ne ho dovuti provare uina decina prima di trovarne uno con l'inconfondibile linux kernel. Può essere OPhone, a sua volta basata su Android. Per chi vuole saperne di più: http://en.wikipedia.org/wiki/OPhone ciao Michael ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Navit on Windows CE
On 01/-10/-28163 08:59 PM, Simone Saviolo wrote: Poi ho cercato di aggiungere mappe scaricate da OSM (non ho intenzione di andare a Monaco entro breve). perché no? è una bella citta, da Milano ti metti cinque ore in macchina, e se vai l'ultimo weekend a settembre, gli annunci nei mezzi sono persino in italiano ;-) Sai inoltre dirmi cosa bisogna fare di preciso per poter usare il GPS? Devo impostare la source wince:com2: su ogni profilo? Ci sono altri accorgimenti? Scegli un singolo vehicle che vuoi utilizzare e imposti vehicle source=wince:com2: baudrate=4800 altri-attributi=a-scelta Bisogna specificare la baudrate; 4800 e lo standard secondo NMEA che funziona per ogni unità GPS. Si può configurare in questo modo un vehicle al massimo perché ogni vehicle, attivo o no, si collega alla sua source subito, ma il port COM permette solo un collegamento. Da WinCE 5 in poi dovresti anche avere la possibilità di impostare come source: vehicle source=wince:GPD1: ... utilizzando il driver GPS interno (al quale si possono collegare anche due o più applicazioni simultaneamente, così non sei più limitato a un singolo vehicle). Puoi anche dare un'occhiata sul wiki di navit [0], dove trovi praticamente tutto sul contenuto di navit.xml e ulteriori informazioni. ciao Michael [0] http://wiki.navit-project.org/index.php/Configuring_Navit#Vehicle ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Navit on Windows CE
On 20:59, Simone Saviolo wrote: Il 06 agosto 2010 20:39, Michael von Glasowmich...@vonglasow.com ha scritto: Ciao, l'eseguibile dovrebbe essere lo stesso in tutti e due casi; può essere che il zip o l'exe è danneggiato. Io lo installo dal CAB (uso Windows Mobile 2003 SE su un Mio 168RS) e fino ad adesso non ho avuto dei problemi, a parte che dopo l'installazione mi dice che il programma è stato creato per una versione precedente di Windows Mobile e perciò potrebbe causare degli errori, ma funziona. Uso anche i miei propri build e anche loro vengono riconosciuti come applicazioni validi. Usi la versione più aggiornata di SVN? (Ti lo consiglio perché l'ultimo build ufficiale è già vecchissimo.) Installa questa del CAB e riprova, dovrebbe funzionare. Ho provato sia la 0.1.1 (zip e cab) sia la current (cab). L'eseguibile dello zip non è un'applicazione WinCE valida. Lanciando il cab mi si apre CabInstall; imposto il percorso di destinazione (sulla SD, dove c'è anche il file cab), clicco su Install, ma poi CabInstall si chiude e apparentemente non fa più niente. Se faccio Extract, mi riempie una cartella con una serie di file con estensione numerata (gli stessi che vedo sul pc aprendo il cab con 7zip), ma non so che cosa farci. Su WinCE sono un niubbo completo e non so neanche bene come muovermi... Ciao, Simone Quale versione di WInCE utilizzi? La mia esperienza è con Windows Mobile 2003 SE e con Windows Mobile 5; su tutti e due sono riuscito ad installare ed eseguire Navit senz'altro. Basta lanciare il cab e Navit si installa automaticamente sotto Program Files (per quanto ne sappia, né WM2003 né WM5 permettono di cambiare il percorso d'installazione.) Estrarre i file a mano non serve perché i nomi sono diversi dentro il cab e vengono cambiati solo durante l'installazione. So però che la versione WinCE di Navit è poca mantenuta, dicono sostanzialmente di averla prodotta perché siamo in grado di farla. Per quanto ne sappia, Windows Mobile 7 ha dei problemi con applicazioni esterni, bisogna versare una somma elevati do soldi a Microsoft e firmare un NDA. Mi viene in mente una cosa... Navit è basato su cegcc, che dice di supportare Windows Mobile 6 da breve, ma sola nella versione SVN. Se usi Windows Mobile 6... può essere per quello. Se hai Ubuntu a mano, puoi scaricare l'ultima versione di cegcc, compilarla, poi scaricare il codice di navit e compilare tutto. Altrimenti fammi sapere, così aprirò un ticket per far aggiornare il build environment alla versione nuova di cegcc. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
