Re: [OSM-talk-fr] [ProjetEOF] - article de blog - Le local d'OSM Burkina est ouvert !
Bravo Augustin pour tout le travail réalisé dans l'Afrique francophone. Eric Le 6 févr. 2015 17:05, Augustin Doury augustindo...@gmail.com a écrit : Bonjour à tous, Un nouvel article de blog est disponible sur le site du Projet Espace OSM Francophone. Cliquez ici : Le local d'OSM Burkina est ouvert ! http://projeteof.org/le-local-dosm-burkina-est-ouvert/ pour découvrir le travail de Janvier et de nouveaux mordus d’OSM. Bonne lecture et WE, gus -- Augustin Doury +22660717822 Projet Espace OpenStreetMap Francophone | projeteof.org | @ProjetEOF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Bei Wanderwegen ist es seit vielen Jahren akzeptierte Praxis, ausgeschilderte Wanderwegnetze als route relation zu mappen. Das greift immer dann wenn es nicht die klassischen Routen von A nach B sind, sondern ein Netzwerk von jeweils an Kreuzungen einheitlich beschilderten Wanderwegen. Das kommt in der Schweiz recht häufig vor, wo die Wanderwege halt offiziell so organisiert sind. Seit langem etabliert, leicht verständlich, keine Abgrenzungsprobleme, gut auswertbar, keine Diskussionen. Ich sehe keinen Grund, warum man bei Radwegenetzen mit vergleichbarem Charakter nicht genauso vorgehen sollte. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Wieder-einmal-lcn-Sammelrelationen-tp5832130p5832770.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Staatliches Gesundheitsamt
Hallo, wie mapt ihr ein Staatliches Gesundheitsamt? office= ? Weder Gesundheitsamt noch health agencies ergaben einen Treffer. Hinzu kommt, dass auch office=administrative nicht ganz stimmt, da es sich um eine staatliche Behörde handelt, deren Kosten aber die Kommune mit trägt (Gebäude bzw Miete stellt) Für eure Ideen schon mal danke. Helmut -- Helmut Kauer Bodelschwinghstraße 35 83301 Traunreut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-be] Address evolution in Belgium
Op 6 februari 2015 20:24 schreef Guy Vanvuchelen guy.vanvuche...@gmail.com : Een probleem is dat soms de nummering van één straat doorloopt in een aanliggende straat. Bijv. de nummering van de Hof ter Mereweg loopt door in de Kosbeekweg. Dus een adres in de Kosbeekweg is eigenlijk: addr: street = Hof ter Mereweg. Hoe moet zoiets gemapt worden. Guy Vanvuchelen Hmm, op afstand kan ik dat jammer genoeg niet onderzoeken. Als ik zo naar de data kijk, dan lijkt het alsof de Kosbeekweg niet eens bestaat, en dat de volledige weg Hof ter Mereweg noemt. Ofwel is de Kosbeekweg een stuk korter dan momenteel getekend (maar tussen de Zavelstraat en de Neerlintersesteenweg). Moest ik dichter wonen, dan zou ik zeker eens ter plaatse gaan kijken naar de naambordjes, en het ook melden aan de gemeente. Het is duidelijk dat de Crab data hier wel ergens fout is, aangezien bepaalde nummers in beide straten voorkomen, op ongeveer dezelfde positie. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-it] open expo 2015
Il 07/feb/2015 02:13 pjhooker lima.cityplan...@gmail.com ha scritto: eheh ... gli edifici che sono stati mappati, li ho messi io cmq io sono in zona, se organizzate una spedizione, magari faccio acnhe qualche ripresa col mio drone Se fai le riprese possiamo poi creare un servizio WMS e utilizzarlo per migliorare la mappa dell'expo Ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
On 02/07/2015 12:28 PM, Henning Scholland wrote: Kleiner Einwand: Auch bei den Netzen für die Zweiradler ist es seit Jahren gängige Praxis die Radwegenetze in entsprechende Relationen zu packen. Wo ist auch der Unterschied (abgesehen von der Länge) ob ich vom Bahnhof zum Zentrum fahre oder von der Quelle der Elbe zu deren Mündung? Für die Länge gibt es lcn/rcn/ncn/icn als Kriterium der Unterscheidung. Weil *ein* Weg zum Bahnhof ausgeschildert ist machst du eine Relation Weg zum Bahnhof draus? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Honga Tonga eintragen, Bildquelle?
Zur Ergänzung: In OSM hat jemand die neue Küstenlinie bereits vor 7 Tagen eingezeichnet. Ohne Quellenangabe. http://www.openstreetmap.org/way/325720273 Am 7. Februar 2015 um 00:57 schrieb Christoph Hormann chris_horm...@gmx.de : On Friday 30 January 2015, Christoph Hormann wrote: [...] In diesem Fall besteht aber nicht wirklich so große Notwendigkeit - in ein paar Wochen gibt es aus den üblichen Quellen, insbesondere Landsat, die ersten rechtlich einwandfreien Quellen, die eine grobe Erfassung ermöglichen würden. Der Vollständigkeit halber: gibt jetzt ein erstes weitgehend wolkenfreies EO1-Bild, was die neue Insel nicht komplett aber größtenteils enthält: http://earthexplorer.usgs.gov/metadata/1852/EO1A0700742015035110KF_PF2_01/ http://www.imagico.de/files/EO1A0700742015035110KF_rgb8.tif -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] [ProjetEOF] - article de blog - Le local d'OSM Burkina est ouvert !
Bravo. Le 7 février 2015 08:38, Eric Debeau eric.deb...@gmail.com a écrit : Bravo Augustin pour tout le travail réalisé dans l'Afrique francophone. Eric Le 6 févr. 2015 17:05, Augustin Doury augustindo...@gmail.com a écrit : Bonjour à tous, Un nouvel article de blog est disponible sur le site du Projet Espace OSM Francophone. Cliquez ici : Le local d'OSM Burkina est ouvert ! http://projeteof.org/le-local-dosm-burkina-est-ouvert/ pour découvrir le travail de Janvier et de nouveaux mordus d’OSM. Bonne lecture et WE, gus -- Augustin Doury +22660717822 Projet Espace OpenStreetMap Francophone | projeteof.org | @ProjetEOF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- -- Henri-Damien LAURENT Abidjan cel : +225 55 80 74 46 / +225 77 84 41 92 tel : +225 22 41 86 05 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
On 02/07/2015 11:20 AM, Michael Reichert wrote: In Karlsruhe gibt es im Stadtgebiet (wie auch im Umland) diese grün-weißen Radroutenschilder. Es sind keine Routen (also mit Symbolen und Namen wie Albtalradweg, sondern einfach das Fahrrad-Äquivalent zu den Pkw-Wegweisern). Beispiel: http://www.mapillary.com/map/im/_Fe4KAuHVBlr0aZwgGLxoQ [1] Das ist auch meine Erfahrung mit diesen Schildern. Der einzige Grund, weshalb ein Router ausgeschilderte Wege bevorzugen sollte, ist die Anweisung Folgen Sie bis zum Bahnübergang dem Enztalradweg.. Das setzt voraus, dass die Beschilderung des Weges lückenfrei ist. :-) Das wäre ein klarer Grund *für* eine Relation. Ein bestimmter Radweg mit Namen der ausgeschildert ist gehört selbstverständlich auch in OpenStreetMap erfasst. Soweit ich das aber verstanden habe geht es hier um eine Sammelrelation in der einfach mal eben alle Wege erfasst werden, auf die einer dieser Wegweiser hinweist. Das einzige, das man mit so einer Relation zeigen kann, ist, dass nur auf einen Bruchteil der zum Radfahren geeigneten Wege mit einem Wegweiser hingewiesen wird. Aber wer braucht so eine Information? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Am 07.02.2015 um 13:02 schrieb Manuel Reimer: On 02/07/2015 12:28 PM, Henning Scholland wrote: Kleiner Einwand: Auch bei den Netzen für die Zweiradler ist es seit Jahren gängige Praxis die Radwegenetze in entsprechende Relationen zu packen. Wo ist auch der Unterschied (abgesehen von der Länge) ob ich vom Bahnhof zum Zentrum fahre oder von der Quelle der Elbe zu deren Mündung? Für die Länge gibt es lcn/rcn/ncn/icn als Kriterium der Unterscheidung. Weil *ein* Weg zum Bahnhof ausgeschildert ist machst du eine Relation Weg zum Bahnhof draus? Ich trage sowas überhaupt nicht ein, weiß nur, dass dies seit Jahren gängige Praxis ist. Mag sein, dass Bahnhof und Zentrum überspitzt waren. Verstehe es als zwei Orte. Aber selbst wenn es Bahnhof und Zentrum wären, wo siehst du den Unterschied zu Quelle - Mündung? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-be] Address evolution in Belgium
Op de kaart van Groot Tienen en op GoogleMaps staan de wegen nochtans ook zo getekend. Ik zal een van de volgende dagen eens gaan kijken want er loopt blijkbaar ook nog een ‘Kospad’ dat nog niet gemapt is. Dat vertrekt vanop het kruispunt van de Hof Ter Mereweg en de Kosbeekweg. In de Gouden Gids zie je dat Hof ter Mereweg 43 in de Kosbeekweg ligt Guy Vanvuchelen Van: Sander Deryckere [mailto:sander...@gmail.com] Verzonden: zaterdag 7 februari 2015 10:45 Aan: OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] Address evolution in Belgium Op 6 februari 2015 20:24 schreef Guy Vanvuchelen guy.vanvuche...@gmail.com: Een probleem is dat soms de nummering van één straat doorloopt in een aanliggende straat. Bijv. de nummering van de Hof ter Mereweg loopt door in de Kosbeekweg. Dus een adres in de Kosbeekweg is eigenlijk: addr: street = Hof ter Mereweg. Hoe moet zoiets gemapt worden. Guy Vanvuchelen Hmm, op afstand kan ik dat jammer genoeg niet onderzoeken. Als ik zo naar de data kijk, dan lijkt het alsof de Kosbeekweg niet eens bestaat, en dat de volledige weg Hof ter Mereweg noemt. Ofwel is de Kosbeekweg een stuk korter dan momenteel getekend (maar tussen de Zavelstraat en de Neerlintersesteenweg). Moest ik dichter wonen, dan zou ik zeker eens ter plaatse gaan kijken naar de naambordjes, en het ook melden aan de gemeente. Het is duidelijk dat de Crab data hier wel ergens fout is, aangezien bepaalde nummers in beide straten voorkomen, op ongeveer dezelfde positie. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] image links in taglocator
2015-02-07 11:31 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: 6. http://www.openstreetmap.org/node/2412547967 Verwijzing naar een website waarop een plaatje is te zien. (Het plaatje is echter in de link NIET opgenomen). Die heb ik gewoon verkeerd gemapped. m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-ca] Suggestion for Restructuring of Québec-Sites in Wiki
Je suis pas mal du même avis que dega, et pour les mêmes raisons. Bruno Le 2015-02-06 17:49, dega gade...@gmail.com a écrit : Salut Niklas! Étant donné que: - les parcs sont de juridiction provinciale - ces parcs sont au Québec - que la langue du Québec est le français - que le nom officiel de ces parcs est en français je suggère que la page Wiki soit en français et que les pages en d'autres langues (eg: innu, atikamekw ou anglais) fassent référence à la page en français. Salutations dega Le 6 février 2015, 12:00:02 talk-ca-requ...@openstreetmap.org a écrit : Date: Thu, 05 Feb 2015 13:12:13 -0500 From: Niklas Rusche n.rus...@gmx.net To: talk-ca@openstreetmap.org Subject: [Talk-ca] Suggestion for Restructuring of Québec-Sites in Wiki Message-ID: 54d3b27d.7060...@gmx.net Content-Type: text/plain; charset=utf-8; format=flowed Hello Everyone, In the attempt to create a wiki-site for the park in Québec, I stumbled upon some inconsistencies in Page-Names and Organisation, that I would like to clean up, if nobody has a problem with it. 1. The Name Convention 'country':'province' eg. Canada:Québec is sometimes used, sometimes not. I would pledge for not using it, because it is... a) a bit bulky b) rarely used in other countries c) unnecessary and incomplete structuring in the wrong place. The information, which city belongs in which province belongs in which country, should be (IMHO) in the content of the article, not in the article name. 2. The language name spaces are often not properly used, which makes it unnecessarily difficult to keep two language versions of articles. To compare: French version now is in the main name space (which is English) http://wiki.openstreetmap.org/wiki/Qu%C3%A9bec My suggestion would look as follows: http://wiki.openstreetmap.org/wiki/FR:Qu%C3%A9bec Looking forward to hear your opinion on this! Niklas (Holzloifer) ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-it] open expo 2015
Si, sarebbe oro. Ciao, Mirco -- View this message in context: http://gis.19327.n5.nabble.com/open-expo-2015-tp5817169p5832786.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Staatliches Gesundheitsamt
Am 7. Februar 2015 um 10:34 schrieb Helmut Kauer li...@helmut-kauer.de: Hallo, wie mapt ihr ein Staatliches Gesundheitsamt? office= ? Weder Gesundheitsamt noch health agencies ergaben einen Treffer. Vielleicht wurde soetwas noch nie gemappt. Hinzu kommt, dass auch office=administrative nicht ganz stimmt, da es sich um eine staatliche Behörde handelt, deren Kosten aber die Kommune mit trägt (Gebäude bzw Miete stellt) Für eure Ideen schon mal danke. office=administrative finde ich eine gute Idee. Es gibt nicht nur staatliche Behörden (die man auch noch zwischen Bund und Ländern differenzieren kann), sondern auch kommunale Behörden etc. Die deutsche Behördenstruktur aus rechtlicher Sicht abbilden zu wollen, dafür fehlt es OSM derzeit an Möglichkeiten und ich glaube auch nicht, dass es für unsere Zwecke notwendig ist. Das ist schon keine raumbezogene Information mehr. Aufgaben und Funktion sind ohnehin von Staat zu Staat verschieden. Einziges ziel kann es meines Erachtens daher sein, dass die Behörde samt Adresse gefunden wird. Derjenige, der weiß, dass er zum Gesundheitsamt der Stadt XY muss, sollte das als Treffer in der Datenbank und damit auch als Kartendarstellung finden. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Hallo, Am 2015-02-06 um 19:21 schrieb Manuel Reimer: On 02/06/2015 02:43 PM, Norbert Renner wrote: Zumindest im Bodenseekreis [1] sind das nicht nur allgemeine Richtungsweiser, sondern es sind konkrete, für Radfahrer besonders geeignete Verbindungen ausgeschildert, mit kleinen Richtungspfeilen an jeder Abzweigung [2]. Das ist eine Meinung eines Landkreises welche Wege besonders geeignet sein *könnten*. Jemand anderes könnte wieder andere Meinungen haben. Machen wir dann für alle diese Möglichkeiten Relationen? In Karlsruhe gibt es im Stadtgebiet (wie auch im Umland) diese grün-weißen Radroutenschilder. Es sind keine Routen (also mit Symbolen und Namen wie Albtalradweg, sondern einfach das Fahrrad-Äquivalent zu den Pkw-Wegweisern). Beispiel: http://www.mapillary.com/map/im/_Fe4KAuHVBlr0aZwgGLxoQ [1] Diese Wegweiser stehen bei uns in Karlsruhe meistens nur dort, wo man auf dem Weg zum Ziel abbiegen muss. Dazwischen stehen *nur selten* die kleinen Richtungsanzeiger [2]. Ich habe vorgestern bei einigen dieser Strecken lcn=yes an den Ways ergänzt, eine Routenrelation fände ich jedoch übertrieben, denn die Routen sind sparsam ausgeschildert. Das Netz ist in OSM noch ziemlich lückig erfasst [4], wobei ich mir nicht sicher bin, ob ich überhaupt lcn=yes taggen sollten und stattdessen lieber die Wegweiser als Relation [3] mappen sollte, wenn man unter Umständen nur alle 1000 Meter auf ein Schild trifft. Meinen Beobachtungen zufolge sind die Routen nicht die besten Strecken zum Radfahren, wenn man eine minimale Fahrtzeit haben möchte. Sie bevorzugen Radwege, die es meist entlang von Hauptstraßen gibt, wo aber die Ampeln einen meist ausbremsen. Auf parallel verlaufenden Wohnstraßen kommt man meist schneller voran. Die Wegweiser sind interessant zur Orientierung aber wozu sollte ich mir mit dem Navi gerade auf diesen Wegen eine Route erstellen lassen? Wenn der Routing-Algorithmus basierend auf den Tags am Weg einene anderen Weg für besser geeignet hält um von A nach B zu kommen, dann ist dieser Weg mindestens genau so gut. Der einzige Grund, weshalb ein Router ausgeschilderte Wege bevorzugen sollte, ist die Anweisung Folgen Sie bis zum Bahnübergang dem Enztalradweg.. Das setzt voraus, dass die Beschilderung des Weges lückenfrei ist. :-) Da die Radrouten gerne auch mit einem ökonomischen Hintergedanken geplant werden (kleiner Umweg, damit auch Gastwirt X noch ein paar Gäste mehr bekommt) und sich an die Zielgruppe Leute, die auf's Rad umsteigen richten, sind sie jedoch nicht immer die beste Wahl. Sie bevorzugen (meine Beobachtung) gerne etwas straßenfernere Wege. Nicht umsonst hat BRoute ein Profil ignore-cycleroutes. :-) Viele Grüße Michael [1] falls ihr Firefox nutzt und nur das obere linke Eck des Bildes seht, müsst ihr einmal rechts ins Bild klicken und auf Element untersuchen klicken (der Bug ist schon gemeldet) [2] https://wiki.openstreetmap.org/wiki/File:Richtungsanzeiger_BW.jpg [3] https://wiki.openstreetmap.org/wiki/Relation:destination_sign [4] http://overpass-turbo.eu/s/7xf -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk-be] image links in taglocator
Naar aanleiding van mijn eerdere bericht over de image links in taglocator en de wijze waarop plaatjes als thumbnail worden afgebeeld, ben ik wat verder gaan uitzoeken hoe die links er uitzien. Hier mijn bevindingen: Ik geef steeds de links naar de betreffende ways/nodes op OSM. Eerst even de links die makkelijk naar een thumbnail kunnen worden omgezet: 1. http://www.openstreetmap.org/way/5013364 Hierbij wordt gelinkt naar http://upload.wikimedia ... 2. http://www.openstreetmap.org/way/32521896 Hierbij wordt gelink naar een plaatje op een prive/bedrijfs site De links die niet (op eenvoudige wijze) tot een thumbnail kunnen worden herleid: 3. http://www.openstreetmap.org/node/2413530151 Hierbij wordt naar flickr verwezen 4. http://www.openstreetmap.org/way/116149697 De verwijzing middels: File: 5. http://www.openstreetmap.org/way/264783489 Verwijzing naar een plaatje op wikipedia (inderdaad NIET wikimedia) 6. http://www.openstreetmap.org/node/2412547967 Verwijzing naar een website waarop een plaatje is te zien. (Het plaatje is echter in de link NIET opgenomen). Ik heb het voorlopig zo opgelost in taglocator dat ik in de gevallen 1 en 2 de thumbnail laat zien en in de gevallen 2-5 gewoon de werkende link (maar dus zonder Thumbnail) laat zien. Bij situatie 6 zie je nog steeds een broken link plaatje. Ondertussen zoek ik naar manieren om wél die thumbnail te kunnen laten zien. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Base de données pour le développement
Le 07/02/2015 14:45, Vincent Frison a écrit : Le 3 février 2015 14:30, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : - Du coup la meilleure solution dans mon cas serait peut-être d'avoir mon propre serveur de données en local ? Je pourrais ainsi importer toutes les données de la France en conservant les IDs originaux du serveur principal. Si j'ai bien compris il faudrait pour cela que j'utilise le schéma apidb (avec l'outil osmosis + certainement plein d'autres choses) et donc au final j'aurai les données OSM en double sur ma base PostGIS en local : - un schéma osm2pgsql me permettant de calculer l'osmId en fonction des coordonnées géographiques de l'immeuble. - un schéma apidb me permettant de simuler l'API en lecture et en écriture. Cela vous semble être la bonne approche ? Bon visiblement mon approche n'a choqué personne donc on va dire qu'elle n'est pas trop mauvaise :) J'ai donc essayé d'installer le 2e schema (apidb) sur mon PostGIS local afin d'y charger les données de PACA et IdF (qui seront largement suffisantes pour tester mes imports de PSS ou d'OpenDataParis). Mais j'ai cette erreur au moment de charger mon fichier PBF : org.openstreetmap.osmosis.core.OsmosisRuntimeException: Database version mismatch. The schema is missing migrations [2016184519], may need to upgrade schema or specify validateSchemaVersion=no. J'ai d'abord essayé avec le package osmosis de Debian Wheezy (version 0.40.1) en chargeant le schema contrib/apidb-06.sql puis je me suis dis que c'était sans doute une version trop vieille version par rapport à mes données fraîchement récupérées sur geofrabrik.de http://geofrabrik.de. J'ai donc téléchargé et compilé osmosis directement depuis Git mais le problème est le même. Ce qui m'étonne c'est que même sur Git le fichier package/script/contrib/apidb_0.6.sql a comme migration la plus récente la 20110925112722. D'ailleurs le fichier n'a pas été touché depuis 3 ans. Du coup je me demande quelle est la bonne procédure à suivre pour charger un schéma apidb (sans devoir mettre l'option validateSchemaVersion=no). Merci, Vincent. En pratique personne n'utilise la l'apidb. Si tu veux faire des tests, l'api de du serveur de dev devrait sufire c'est des cas biens définit. Sur les données, tu as également le schéma de base osmosis qui est plus proche de celui de l'api que de osm2pgsql qui est initialement destiné au rendu et dont le contenu de la base résultante est partiel. Mon avis est, comme cela a déjà était dit, est que tu veux mettre la charrue avant les bœufs. S'assurer et obtenir une licence/accord de l'utilisation des données est primordial, et peut prendre plus de temps et être finalement plus compliqué que les aspects techniques. My 2 cents. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-ht] limites administratives PAP/zòn PAP
Bonjour, j’ai vu qu’il y avait des erreurs au niveau des délimitations administratives dans la zone de PAP. J’ai voulu réparer mais cela s’est mal passé, du notamment à un bogue dans JOSM et on se retrouve avec des données erronées. Je vais m’atteler à réparer les erreurs d’ici la semaine qui vient. Bonjou mwen te we te gen pwoblem nan limit komin nan zòn PAP. mwen te eseye ranje mè li te bay lòt pwoblem. mwen pral travay nan semanm sa pou repare yo. Xavier ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [Talk-it] Tram in sede stradale
Ma il tram di Padova com'é taggato? Dovrebbe essere la stessa situazione, si potrebbe utilizzarlo in questo caso. Il 07/feb/2015 14:57 Luca Sigfrido Percich luca.perc...@gmail.com ha scritto: Ciao Volker, per me sta bene, spero comunque di sentire il parere di qualcuno della community italiana. Mi pare strano che i tram in sede stradale siano territorio inesplorato :) Grazie Sig Il 07/Feb/2015 08:43 Volker Schmidt vosc...@gmail.com ha scritto: Posso proporre di spostare la discussione sulla lista tagging: [Tagging] Tram tracks running in a road Inutile avere due discussioni in parallelo sullo stesso argomento. Volker 2015-02-06 16:00 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com : Ciao Mauro, grazie a te per aver partecipato alla discussione. Il giorno 6 febbraio 2015 12:41, Mauro Costantini maurocostantini1...@gmail.com ha scritto: La mia idea, non sempre condivisa da altri mappatori, è che railway e highway vadano *sempre* distinte. La condivido. Dando per assodato che il rappresentare le railway come geometricamente distinte sia il modo migliore (viste le problematiche di tagging di cui parli), cerchiamo di ragionare sulla relazione con le strade nel caso in cui il tram viaggi in sede stradale insieme alle auto. In questi casi generalmente ho una highway centrale e due railway laterali. Per cercar di ricondurre queste due modalità di tagging al [caso uno] (due ways distinte, vicine e parallele) senza perdere l'informazione i due oggetti appartengono alla stessa strada è a disposizione la relazione http://wiki.openstreetmap.org/wiki/Relation:street . Nella relazione andranno tutti i valori comuni alle due ways (o più ways in caso di marciapiedi mappati separatamente, di ways spezzate anche per altri motivi, ecc...) lasciando sui singoli elementi solo i tags specifici. La wiki è piuttosto scarna e la relazione è solo una proposta. Non mi è chiaro se è stata pensata per raggruppare tutte le ways di una intera via, o di una sezione di via da incrocio a incrocio. Sembrerebbe la prima, quindi poco utilizzabile. Non mi interessa tanto sapere che quella railway è in Corso Ventidue marzo quanto che quella railway corre dentro quella highway. Non possiamo risolvere parzialmente il problema con l'uso di tags? Sulle highway_: tram=forward oppure lanes=6 lanes:forward=3 tram:lanes:forward=yes|no|no e sulle railway corrispondenti: road=yes (un po' in analogia con bridge e tunnel) Se, ad esempio, una way nel [caso due] avesse entrambi i marciapiedi andrebbe segnalato da che lato si trovano i marciapiedi rispetto alle due nuove ways: cioè sidewalk=both andrebbe probabilmente spezzata in sidewalk=left su un elemento e sidewalk=right sull'altro. Il problema è che la highway centrale rappresenta tutta la carreggiata, compreso lo spazio in cui passano i binari. Invece le railway rappresentano il solo tracciato dei binari. Quindi tutte le informazioni su marciapiedi, sosta e quant'altro di cui parli rimarrebbero concettualmente legate alla way centrale. Inoltre ai tag del tipo highway=crossing (e railway=crossing) andrebbe aggiunto il footway tra una way e l'altra per non rompere il routing pedonale. Meglio ancora, in casi critici come questi, mappare separatamente i marciapiedi (highway=footway + footway=sidewalk) e raggruppare le quattro ways (più gli eventuali attraversamenti) in una street relation. A questo non avevo pensato. Mi sembra estremamente laborioso aggiungere i marciapiedi come way separate ovunque ci siano i tram. Riusciamo a elencare i casi d'uso del dato e quali problemi potrebbero avere l'una o l'altra rappresentazione, ovvero routing (pedonale), rendering etc.? Nel frattempo cerco di sondare in lista tagging Sig ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-be] image links in taglocator
Marc, ik vind je de verkeerde mensen beloond. Mensen die zomaar foto's van het internet plukken, zonder zich te bekommeren om de licentie van de maker van die foto, daarvan ga je een thumbnail tonen. Misschien mag die foto link (bv. naar dat bedrijf) wel helemaal niet gebruikt worden. Dus voor mij moet je alle foto's die niet van een correcte licentie voorzien zijn, overplakken of rood markeren of ... met mogelijks licentiebreuk overschrijven of iets dergelijks. Ik denk dat er zelfs al een probleem is bij die foto van de Eifeltoren, omdat er niet naar de juiste pagina met licentie verwezen wordt. De flickr foto is misschien een probleem, maar sommigen hebben wel een CC-share-alike achtige licentie Zou netzwolf [1] je niet kunnen helpen met enkel de foto's met een goede licentie te tonen ? mvg m [1] http://wiki.openstreetmap.org/wiki/User:Netzwolf Voor 2015-02-07 11:31 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Naar aanleiding van mijn eerdere bericht over de image links in taglocator en de wijze waarop plaatjes als thumbnail worden afgebeeld, ben ik wat verder gaan uitzoeken hoe die links er uitzien. Hier mijn bevindingen: Ik geef steeds de links naar de betreffende ways/nodes op OSM. Eerst even de links die makkelijk naar een thumbnail kunnen worden omgezet: 1. http://www.openstreetmap.org/way/5013364 Hierbij wordt gelinkt naar http://upload.wikimedia ... 2. http://www.openstreetmap.org/way/32521896 Hierbij wordt gelink naar een plaatje op een prive/bedrijfs site De links die niet (op eenvoudige wijze) tot een thumbnail kunnen worden herleid: 3. http://www.openstreetmap.org/node/2413530151 Hierbij wordt naar flickr verwezen 4. http://www.openstreetmap.org/way/116149697 De verwijzing middels: File: 5. http://www.openstreetmap.org/way/264783489 Verwijzing naar een plaatje op wikipedia (inderdaad NIET wikimedia) 6. http://www.openstreetmap.org/node/2412547967 Verwijzing naar een website waarop een plaatje is te zien. (Het plaatje is echter in de link NIET opgenomen). Ik heb het voorlopig zo opgelost in taglocator dat ik in de gevallen 1 en 2 de thumbnail laat zien en in de gevallen 2-5 gewoon de werkende link (maar dus zonder Thumbnail) laat zien. Bij situatie 6 zie je nog steeds een broken link plaatje. Ondertussen zoek ik naar manieren om wél die thumbnail te kunnen laten zien. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Base de données pour le développement
Le 3 février 2015 14:30, Vincent Frison vincent.fri...@gmail.com a écrit : - Du coup la meilleure solution dans mon cas serait peut-être d'avoir mon propre serveur de données en local ? Je pourrais ainsi importer toutes les données de la France en conservant les IDs originaux du serveur principal. Si j'ai bien compris il faudrait pour cela que j'utilise le schéma apidb (avec l'outil osmosis + certainement plein d'autres choses) et donc au final j'aurai les données OSM en double sur ma base PostGIS en local : - un schéma osm2pgsql me permettant de calculer l'osmId en fonction des coordonnées géographiques de l'immeuble. - un schéma apidb me permettant de simuler l'API en lecture et en écriture. Cela vous semble être la bonne approche ? Bon visiblement mon approche n'a choqué personne donc on va dire qu'elle n'est pas trop mauvaise :) J'ai donc essayé d'installer le 2e schema (apidb) sur mon PostGIS local afin d'y charger les données de PACA et IdF (qui seront largement suffisantes pour tester mes imports de PSS ou d'OpenDataParis). Mais j'ai cette erreur au moment de charger mon fichier PBF : org.openstreetmap.osmosis.core.OsmosisRuntimeException: Database version mismatch. The schema is missing migrations [2016184519], may need to upgrade schema or specify validateSchemaVersion=no. J'ai d'abord essayé avec le package osmosis de Debian Wheezy (version 0.40.1) en chargeant le schema contrib/apidb-06.sql puis je me suis dis que c'était sans doute une version trop vieille version par rapport à mes données fraîchement récupérées sur geofrabrik.de. J'ai donc téléchargé et compilé osmosis directement depuis Git mais le problème est le même. Ce qui m'étonne c'est que même sur Git le fichier package/script/contrib/apidb_0.6.sql a comme migration la plus récente la 20110925112722. D'ailleurs le fichier n'a pas été touché depuis 3 ans. Du coup je me demande quelle est la bonne procédure à suivre pour charger un schéma apidb (sans devoir mettre l'option validateSchemaVersion=no). Merci, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Tram in sede stradale
Ciao Volker, per me sta bene, spero comunque di sentire il parere di qualcuno della community italiana. Mi pare strano che i tram in sede stradale siano territorio inesplorato :) Grazie Sig Il 07/Feb/2015 08:43 Volker Schmidt vosc...@gmail.com ha scritto: Posso proporre di spostare la discussione sulla lista tagging: [Tagging] Tram tracks running in a road Inutile avere due discussioni in parallelo sullo stesso argomento. Volker 2015-02-06 16:00 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: Ciao Mauro, grazie a te per aver partecipato alla discussione. Il giorno 6 febbraio 2015 12:41, Mauro Costantini maurocostantini1...@gmail.com ha scritto: La mia idea, non sempre condivisa da altri mappatori, è che railway e highway vadano *sempre* distinte. La condivido. Dando per assodato che il rappresentare le railway come geometricamente distinte sia il modo migliore (viste le problematiche di tagging di cui parli), cerchiamo di ragionare sulla relazione con le strade nel caso in cui il tram viaggi in sede stradale insieme alle auto. In questi casi generalmente ho una highway centrale e due railway laterali. Per cercar di ricondurre queste due modalità di tagging al [caso uno] (due ways distinte, vicine e parallele) senza perdere l'informazione i due oggetti appartengono alla stessa strada è a disposizione la relazione http://wiki.openstreetmap.org/wiki/Relation:street . Nella relazione andranno tutti i valori comuni alle due ways (o più ways in caso di marciapiedi mappati separatamente, di ways spezzate anche per altri motivi, ecc...) lasciando sui singoli elementi solo i tags specifici. La wiki è piuttosto scarna e la relazione è solo una proposta. Non mi è chiaro se è stata pensata per raggruppare tutte le ways di una intera via, o di una sezione di via da incrocio a incrocio. Sembrerebbe la prima, quindi poco utilizzabile. Non mi interessa tanto sapere che quella railway è in Corso Ventidue marzo quanto che quella railway corre dentro quella highway. Non possiamo risolvere parzialmente il problema con l'uso di tags? Sulle highway_: tram=forward oppure lanes=6 lanes:forward=3 tram:lanes:forward=yes|no|no e sulle railway corrispondenti: road=yes (un po' in analogia con bridge e tunnel) Se, ad esempio, una way nel [caso due] avesse entrambi i marciapiedi andrebbe segnalato da che lato si trovano i marciapiedi rispetto alle due nuove ways: cioè sidewalk=both andrebbe probabilmente spezzata in sidewalk=left su un elemento e sidewalk=right sull'altro. Il problema è che la highway centrale rappresenta tutta la carreggiata, compreso lo spazio in cui passano i binari. Invece le railway rappresentano il solo tracciato dei binari. Quindi tutte le informazioni su marciapiedi, sosta e quant'altro di cui parli rimarrebbero concettualmente legate alla way centrale. Inoltre ai tag del tipo highway=crossing (e railway=crossing) andrebbe aggiunto il footway tra una way e l'altra per non rompere il routing pedonale. Meglio ancora, in casi critici come questi, mappare separatamente i marciapiedi (highway=footway + footway=sidewalk) e raggruppare le quattro ways (più gli eventuali attraversamenti) in una street relation. A questo non avevo pensato. Mi sembra estremamente laborioso aggiungere i marciapiedi come way separate ovunque ci siano i tram. Riusciamo a elencare i casi d'uso del dato e quali problemi potrebbero avere l'una o l'altra rappresentazione, ovvero routing (pedonale), rendering etc.? Nel frattempo cerco di sondare in lista tagging Sig ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-GB] import / mech edit of some Aberdeen city council open data
I'm here at http://codethecity.org and neiljp has just arrived, too, and we are egging one another on to import some Aberdeen city council open data into OSM. Specifically looking at this dataset of schools with point locations: http://open311.xoverto.com/dev/v1/facilities/schools.json An overpass query reveals a mix of node and way data for schools existing, with nothing like the same coverage. Would people be broadly okay with this / should we be following a process through the list? The data is OGL licensed. zx -- Jo Walsh metaz...@fastmail.net ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-de] Beispielhafte OSM-Nutzung für Online-Artikel gesucht
Hallo Leute, die Open-Data-Arbeitsgruppe des Landes NRW (Open.NRW) möchte einen Online-Artikel über OSM veröffentlichen, in dem die Vorteile von offenen Geodaten durch einen konkreten Nutzungsfall beschrieben werden. Dafür suchen wir einen OSM-Benutzer, der mit OSM-Daten oder -Karten etwas machen konnte, was er ohne OSM nicht hätte umsetzen können, z.B. weil die kommerziellen Lizenzen zu teuer oder restriktiv gewesen wären oder die Daten von OSM besser waren. Das muss nichts spektakuläres sein, z.B. fällt mir spontan eine Nutzung der Karte im Schulunterricht o.ä. ein. Wenn Du Lust hast der zuständigen Redakteurin Deine OSM-Nutzung kurz zu beschreiben und mit Namen in dem Beitrag auftauchen magst, würde ich mich über eine Mail sehr freuen. Dann stelle ich den Kontakt her. Beste Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-be] image links in taglocator
Op 7 feb. 2015, om 17:07 heeft Marc Gemis marc.ge...@gmail.com het volgende geschreven: Ik denk dat er zelfs al een probleem is bij die foto van de Eifeltoren, omdat er niet naar de juiste pagina met licentie verwezen wordt. Als je even verder zoekt: a title=Door Benh LIEU SONG (Eigen werk) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons href=https://commons.wikimedia.org/wiki/File%3ATour_Eiffel_Wikimedia_Commons.jpg;img width=256 alt=Tour Eiffel Wikimedia Commons src=//upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Tour_Eiffel_Wikimedia_Commons.jpg/256px-Tour_Eiffel_Wikimedia_Commons.jpg//a En dat geldt voor alle andere foto’s die met die link (upload.wikimedia.org) beschikbaar zijn. Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] image links in taglocator
En wat wil CC BY-SA 3.0 zeggen ? [1] volgens mij moet je dus de maker vermelden als je de foto gebruikt, en dat doe je dus niet als je enkel een thumbnail toont die naar de upload pagina verwijst. Dus is dat verkeerd gebruik van de foto. mvg m [1] https://creativecommons.org/licenses/by-sa/3.0 2015-02-07 20:30 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Op 7 feb. 2015, om 17:07 heeft Marc Gemis marc.ge...@gmail.com het volgende geschreven: Ik denk dat er zelfs al een probleem is bij die foto van de Eifeltoren, omdat er niet naar de juiste pagina met licentie verwezen wordt. Als je even verder zoekt: a title=Door Benh LIEU SONG (Eigen werk) [CC BY-SA 3.0 ( http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons href= https://commons.wikimedia.org/wiki/File%3ATour_Eiffel_Wikimedia_Commons.jpg;img width=256 alt=Tour Eiffel Wikimedia Commons src=// upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Tour_Eiffel_Wikimedia_Commons.jpg/256px-Tour_Eiffel_Wikimedia_Commons.jpg //a En dat geldt voor alle andere foto’s die met die link ( upload.wikimedia.org) beschikbaar zijn. Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] image links in taglocator
Op 7 feb. 2015, om 17:07 heeft Marc Gemis marc.ge...@gmail.com het volgende geschreven: Zou netzwolf [1] je niet kunnen helpen met enkel de foto's met een goede licentie te tonen ? Ik heb contact met hem gezocht ivm. het niet functioneren van een aantal van zijn javascript bibliotheken op bv. de iPad, maar hij reageert niet. Ik heb wel al gekeken hoe het wordt opgelost op deze site: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=15lat=51.201lon=4.4648layers=BFFFTFFFTFFFTselect=w218856275 maar daar wordt gebruik gemaakt van een stukje (niet Open Source!) php-code om de inhoud van de webpagina waar het plaatje op staat te analyseren. Dat is de reden waarom het soms lang duurt voordat het plaatje zichtbaar wordt. Ik blijf zelf ook zoeken. groeten, Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] image links in taglocator
Op 7 feb. 2015, om 20:40 heeft Marc Gemis marc.ge...@gmail.com het volgende geschreven: En wat wil CC BY-SA 3.0 zeggen ? [1] volgens mij moet je dus de maker vermelden als je de foto gebruikt, en dat doe je dus niet als je enkel een thumbnail toont die naar de upload pagina verwijst. Dus is dat verkeerd gebruik van de foto. Volgens mij wordt die foto op talloze plaatsen in wikipedia zelf gebruikt: https://commons.wikimedia.org/wiki/File:Tour_Eiffel_Wikimedia_Commons.jpg Wat moet er dan nog meer aan veranderen? En wat dat betreft: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=15lat=51.201lon=4.4648layers=BFFFTFFFTFFFTselect=w218856275 Waar staat dan bij deze foto wie de maker is? En een maker van een foto is volgens mij altijd een persoon, niet een bedrijf/stichting/organisatie. Zelfs op de link naar de bijhorende website kan ik die niet ontdekken. Ik vind deze hele discussie inmiddels nergens meer over gaan. Het lijkt wel op „straf de brenger van het slechte nieuws” omdat ik laat zien dat er plaatjes bij sommige objecten in de database van OSM zitten. In alle gevallen brengen de links die nu in taglocator heb zitten je altijd bij de juiste pagina met de juiste rechtenvermeldingen en in het geval van flickr is er ook niets mis want iedereen die daar zijn foto’s publiek maakt, geeft ook toestemming om ze te bekijken. Commercieel gebruik is niet mogelijk als dat niet expliciet is toegestaan of overeengekomen. groeten, Marc ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] image links in taglocator
Marc, ik wil je niet straffen, ik wil je enkel vragen om niet commons-wikimedia files aan te geven met een kleurtje, zodat mappers weten dat het hier niet over open data gaat (zoals al de rest van OSM). OSM normaal gezien gebruikt worden voor commerciële doeleinden, zonder bijkomende beperkingen. Met die niet-commons-wikimedia files breekt de mapper deze licentie. mvg m 2015-02-07 21:10 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Op 7 feb. 2015, om 20:40 heeft Marc Gemis marc.ge...@gmail.com het volgende geschreven: En wat wil CC BY-SA 3.0 zeggen ? [1] volgens mij moet je dus de maker vermelden als je de foto gebruikt, en dat doe je dus niet als je enkel een thumbnail toont die naar de upload pagina verwijst. Dus is dat verkeerd gebruik van de foto. Volgens mij wordt die foto op talloze plaatsen in wikipedia zelf gebruikt: https://commons.wikimedia.org/wiki/File:Tour_Eiffel_Wikimedia_Commons.jpg Wat moet er dan nog meer aan veranderen? En wat dat betreft: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=15lat=51.201lon=4.4648layers=BFFFTFFFTFFFTselect=w218856275 Waar staat dan bij deze foto wie de maker is? En een maker van een foto is volgens mij altijd een persoon, niet een bedrijf/stichting/organisatie. Zelfs op de link naar de bijhorende website kan ik die niet ontdekken. Ik vind deze hele discussie inmiddels nergens meer over gaan. Het lijkt wel op „straf de brenger van het slechte nieuws” omdat ik laat zien dat er plaatjes bij sommige objecten in de database van OSM zitten. In alle gevallen brengen de links die nu in taglocator heb zitten je altijd bij de juiste pagina met de juiste rechtenvermeldingen en in het geval van flickr is er ook niets mis want iedereen die daar zijn foto’s publiek maakt, geeft ook toestemming om ze te bekijken. Commercieel gebruik is niet mogelijk als dat niet expliciet is toegestaan of overeengekomen. groeten, Marc ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-GB] import / mech edit of some Aberdeen city council open data
Ugh, okay, we had it from the horse's mouth so to speak that the license on the new CKAN catalogue would be OGL. I will sanity check this today. To their credit they are very sensitive to issues surrounding OS derived works. It is quietly wonderful to hear a local authority rep talking of QGIS and GeoJSON in a perfectly natural manner. neiljp went a lot further digging around with Overpass looking for matching names as well as tagged amenities, and there's a decent quantity of way rather than node data there already, so any import will be manual not semi-automated The feedback is apprec, Dan S On Sat, Feb 7, 2015, at 09:31 PM, Dan S wrote: Hi Jo, How do you know it's OGL licensed? I went to try and find the licence and I found this page: http://www.aberdeencity.gov.uk/open_data/education_learning.asp where the licence is stated to be CC-BY-SA-3, which cannot be imported into OSM (because the SA constraint means it can't be relicensed as ODBL). I can't be certain that I found the same schools data (...in fact it has 72 vs 70 items in it...), but I guess at some point the imports-list would demand proper proof that it's available under a compatible licence. They'd also ask how the lat/lon were found (did it involve OS? google?), since that's been an issue with some imports. From my point of view, this is a simple and small dataset and I personally would not object to an import as long as duplicates were avoided etc. Others probably feel different. It's mainly the licence question for me. Oh and I don't live anywhere near Aberdeen ;) Best Dan 2015-02-07 17:24 GMT+00:00 Jo Walsh metaz...@fastmail.net: I'm here at http://codethecity.org and neiljp has just arrived, too, and we are egging one another on to import some Aberdeen city council open data into OSM. Specifically looking at this dataset of schools with point locations: http://open311.xoverto.com/dev/v1/facilities/schools.json An overpass query reveals a mix of node and way data for schools existing, with nothing like the same coverage. Would people be broadly okay with this / should we be following a process through the list? The data is OGL licensed. zx -- Jo Walsh metaz...@fastmail.net ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] import / mech edit of some Aberdeen city council open data
Hi Jo, How do you know it's OGL licensed? I went to try and find the licence and I found this page: http://www.aberdeencity.gov.uk/open_data/education_learning.asp where the licence is stated to be CC-BY-SA-3, which cannot be imported into OSM (because the SA constraint means it can't be relicensed as ODBL). I can't be certain that I found the same schools data (...in fact it has 72 vs 70 items in it...), but I guess at some point the imports-list would demand proper proof that it's available under a compatible licence. They'd also ask how the lat/lon were found (did it involve OS? google?), since that's been an issue with some imports. From my point of view, this is a simple and small dataset and I personally would not object to an import as long as duplicates were avoided etc. Others probably feel different. It's mainly the licence question for me. Oh and I don't live anywhere near Aberdeen ;) Best Dan 2015-02-07 17:24 GMT+00:00 Jo Walsh metaz...@fastmail.net: I'm here at http://codethecity.org and neiljp has just arrived, too, and we are egging one another on to import some Aberdeen city council open data into OSM. Specifically looking at this dataset of schools with point locations: http://open311.xoverto.com/dev/v1/facilities/schools.json An overpass query reveals a mix of node and way data for schools existing, with nothing like the same coverage. Would people be broadly okay with this / should we be following a process through the list? The data is OGL licensed. zx -- Jo Walsh metaz...@fastmail.net ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] Index R*-Tree pour système embarqué
Le 6 février 2015 00:03, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 5 févr. 2015 19:08, Philippe Verdy verd...@wanadoo.fr a écrit : Le test se base sur le fait que tes R*trees ne sont pas maintenus équilibrés en contenu, une règle commune aux B-trees). Et quitte à diviser un rectangle R*tree en deux quand il est plein, on a normalement intérêt à le couper de préférence sur sa dimension la plus grande pour répartir les points de chaque côté (mais si on veut optimiser, on fait le test de répartition sur une dimensio puis sur l'autre, et on choisit celle où le trait de découpe est plus près du milieu de cette dimension). La charge des R*trees doit normalement être portée sur la répartition, lors de l'insertion (ou la suppression) des noeuds, pour qu'ensuite les recherches n'aient pas à le faire. Dans ce cas avec un Quadtree tu génères pleins de boites vides et les branches de l'arbre sont moins bien équilibrées, avec un seuil minimum de remplissage de 25% là où un R*Tree utilise un minimum de 50% (arrondi à l'unité inférieure) : si ton R*tree a une capacité maximale de 6 points ou sous-rectangles, et une capacité minimale de 3 points ou sous-rectangles, c'est à dire 50% pour la répartition la plus optimale, le nombre de boites à visiter ne dépend pas de la distribution des points dans les boites seulement traversées mais sans point, mais seulement du nombre total de points, et le nombre de boites à visiter est en O(log_6(N) où N est le nombre total de noeuds, alors que le Quad-Tree ajoute des tas de points artificiels au centre des boites traversées sans noeud et est seulement en O(.log_4(N+k*S)) où S est le nombre total de segments et k une variable liée à la distribution des longueurs de segments. Les deux index que tu commentes sont en fait des cas particuliers des B-arbres. Normalement tu devrais assurer pendant le remplissage que toutes les branches vers les boites feuilles sont à la même profondeur : tu descent au maximum pour trouver la boite qui matche, tu vois si elle a encore de la place pour le noeud à y ajouter (sauf que dans tes deux arbres les places sont dédiées géométriquement, avec une séparation horizontale et une séparation verticale, soit au centre dans les quadtree, soit arbitraire, du moment que les 4 noeuds peuvent tenir. S'il n'y a plus de place, tu dois découper la boite en 4 et les réindexer aux boites parentes et ses voisines pour les placer de la même façon, en tentant de conserver le seuil minimum de remplissage. Même chose en suppression. Si tu ne fais pas ça tes arbres sont très déséquilibrés : la méthode naïve (seulement descendante) se contente de couper la boite feuille en 4 pour y créer 4 branches et s'arrête là. Ca va très vite en insertion, en revanche très vite ton arbre est fortement déséquilibré. L'optimisation d'un B-arbre consiste à compacter les noeuds de l'arbre de façon transversale entre toutes les branches de même niveau de profondeur. C'est long à faire en cours de modif mais c'est possible une fois l'arbre rempli car on a des statistiques de poids total de chaque branche. Il y a plein de littérature sur la manipulation des B-arbres depuis des décennies et c'est employé depuis longtemps dans toutes les bases de données pour gérer leurs index. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ca] Suggestion for Restructuring of Québec-Sites in Wiki
Salut, C'est aucune question que la langue principale de la communauté à Québec est français. Ce que je voulais dire, c'est que la structure de la base de données du site web http://wiki.openstreetmap.org; est conçu multilingue, ainsi il y a des sections pour les langues. Parce-que OSM est un projet international, la section (espace de noms main, sans préfixe) est en anglais. Les autres langues ont des préfixes, FR: est le préfixe pour l'espace de noms français, DE: pour allemand etc. L'espace de noms EN: n'existe pas. C'est une bonne idée, parce comme ça, on peut utiliser la fonction de recherche seulement pour les résultats françaises. On peut aussi utiliser la fonction de traduction sans peine. Par exemple, regardez http://wiki.openstreetmap.org/wiki/Montr%C3%A9al et http://wiki.openstreetmap.org/wiki/FR:Montr%C3%A9al une autre exemple est Berlin, ou la site en anglais est seulement un redirect à la page DE:Berlin en allemand: http://wiki.openstreetmap.org/wiki/Berlin Ce n’est pas mon intention de déprécier le français, en fait, je fais l'effort de l'apprendre comme troisième langue. Mon intention est juste de profiter de la technologie donnée pour nous simplifier la vie. J'espère que vous comprenez, Cordialement, Niklas Am 07.02.2015 um 07:36 schrieb Bruno Remy: Je suis pas mal du même avis que dega, et pour les mêmes raisons. Bruno Le 2015-02-06 17:49, dega gade...@gmail.com mailto:gade...@gmail.com a écrit : Salut Niklas! Étant donné que: - les parcs sont de juridiction provinciale - ces parcs sont au Québec - que la langue du Québec est le français - que le nom officiel de ces parcs est en français je suggère que la page Wiki soit en français et que les pages en d'autres langues (eg: innu, atikamekw ou anglais) fassent référence à la page en français. Salutations dega Le 6 février 2015, 12:00:02 talk-ca-requ...@openstreetmap.org mailto:talk-ca-requ...@openstreetmap.org a écrit : Date: Thu, 05 Feb 2015 13:12:13 -0500 From: Niklas Rusche n.rus...@gmx.net mailto:n.rus...@gmx.net To: talk-ca@openstreetmap.org mailto:talk-ca@openstreetmap.org Subject: [Talk-ca] Suggestion for Restructuring of Québec-Sites in Wiki Message-ID: 54d3b27d.7060...@gmx.net mailto:54d3b27d.7060...@gmx.net Content-Type: text/plain; charset=utf-8; format=flowed Hello Everyone, In the attempt to create a wiki-site for the park in Québec, I stumbled upon some inconsistencies in Page-Names and Organisation, that I would like to clean up, if nobody has a problem with it. 1. The Name Convention 'country':'province' eg. Canada:Québec is sometimes used, sometimes not. I would pledge for not using it, because it is... a) a bit bulky b) rarely used in other countries c) unnecessary and incomplete structuring in the wrong place. The information, which city belongs in which province belongs in which country, should be (IMHO) in the content of the article, not in the article name. 2. The language name spaces are often not properly used, which makes it unnecessarily difficult to keep two language versions of articles. To compare: French version now is in the main name space (which is English) http://wiki.openstreetmap.org/wiki/Qu%C3%A9bec My suggestion would look as follows: http://wiki.openstreetmap.org/wiki/FR:Qu%C3%A9bec Looking forward to hear your opinion on this! Niklas (Holzloifer) ___ Talk-ca mailing list Talk-ca@openstreetmap.org mailto:Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-br] Relation:boundary
Quando eu for alterar alguma boundary vou passar a verificar o Geocodigo tbm. Abraços --- Mensagem Original --- De: Vitor George vitor.geo...@gmail.com Enviado: 6 de fevereiro de 2015 17:53 Para: OpenStreetMap no Brasil talk-br@openstreetmap.org Assunto: Re: [Talk-br] Relation:boundary Acho importante colocar o IBGE:GEOCODIGO, aqui tem uma lista das cidades brasileiras: https://github.com/vgeorge/b5500/blob/master/data/cities.csv O admin_centre é bom porque podemos extrair depois uma base de cidades de pontos, muito úteis para infográficos. Também dá para usar o role label para áreas muito grandes, como no estado de SP: http://www.openstreetmap.org/relation/298204 Pra quem não conhece o wiki ainda: http://wiki.osm.org/wiki/Relation:boundary 2015-02-04 22:20 GMT-02:00 Lists li...@gimnechiske.org: admin_center pode indicar prioridade em indexar, mas não da muito diferencia para renderizar. Por exemplo voce quer indexar ruas num município, voce quer todos os ruas em ordem alfabético no cidade cede do município primeiro, depois cada outro cidade/vila/distrito em ordem alfabético, com os ruas em ordem alfabético. No este caso admin_center vai te indicar onde começar este registro. Sem admin_center voce pode tenta combinar pelo nome, mas este também pode criar duvidas, não em tudo casos o admin_center tem mesmo nome como município, e as vezes pode ter mais que um ocorrência da nome dentro o município, por exemplo pode ter distrito e subdistrito com mesmo nome. Em caso do estado, nenhuma tem capital com mesmo nome como estado. Aun Johnsen On Feb 4, 2015, at 21:12, Vítor Rodrigo Dias vitor.d...@gmail.com wrote: O Nelson disse que não é obrigatório, mas é bom ter admin_centre. Pelo que entendi, o admin_centre é importante no roteamento do renderizador usado pelo Marcio. Sendo assim, creio que podemos adotar oficialmente o admin_centre como padrão para as relações de municípios e distritos. Em 4 de fevereiro de 2015 21:59, thunder...@gpsinfo.com.br escreveu: Nelson, sem duvida o Brasil é grande e falta muita coisa para arrumar. Até me comprometo a auxiliar nessa empreitada, mas identifico de suma importância que cheguemos a um consenso do que deve ser inserido e o que não deve. Com isso estabelecemos um padrão a ser seguido por todos aqueles que desejarem ajudar. -Mensagem Original- From: Nelson A. de Oliveira Sent: Wednesday, February 4, 2015 9:46 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Relation:boundary 2015-02-04 21:40 GMT-02:00 thunder...@gpsinfo.com.br: Nelson, agregaria para cidade o admin_centre se ela for a sede do estado ou município. Existem inúmeras cidades dentro de um estado e/ou município e, na minha opinião, tem de existir um diferenciador para elas. Isso. Mas essa parte já faz parte dos membros da relação. A relação em si só precisa ter aquelas tags que eu falei anteriormente. Nos membros da relação só é obritagatório os caminhos externos (outer). admin_centre não é obrigatório mas é bom ter. Acho que todos aqui que arrumam os limites acabam colocando o admin_centre. O problema é que o Brasil é grande e falta muita coisa pra arrumar. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Vítor Rodrigo Dias Revisor de textos Tradutor port/ing/port e port/esp/port Telefone: (31) 7360-9421 - TIM ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-ja] 道路規制
surgical21さんへ 道路のaccess:*の道路の区分が日本の法制度と合致しておらず,入力しにくいの で改正を提案します。 「入力しにくい」と言うのは私も同感です。 なので、日本の交通標識との対応表を作ってみた。（作りかけ） https://wiki.openstreetmap.org/wiki/JA_talk:Japan_Tagging_%E4%BA%A4%E9%80%9A%E6%A8%99%E8%AD%98 （議論） 標識のリストアップで力尽きました。 どなたでもタグ付けがわかるものがありましたら書き加えていただきたいです。 surgical21さんの改正案は「Key:access_JP https://wiki.openstreetmap.org/wiki/User:Surgical21/Key:access_JP 」のページの改訂を希望しているようですが、このページは翻訳ページなので日本だけの記述内容に変更するのはちょっと・・・ まずは、標識との対応表を埋めていき、OSMタグに対応できていない項目をリストアップしてみませんか。（ちょっと埋めただけでも対応不能な標識がたくさんある感じです） ribbonさん シニアカーはどこに入るのでしょう? シニアカーは道交法上は歩行者扱い。電動車椅子(wheelchair)と同じ扱いにして良いと思います。 2015年2月6日 23:31 ribbon o...@ns.ribbon.or.jp: On Wed, Feb 04, 2015 at 07:58:58PM +, surgicalmaskman wrote: はじめまして。surgical21と申します。 道路のaccess:*の道路の区分が日本の法制度と合致しておらず,入力しにくいの で改正を提案します。 私案がこちら( https://wiki.openstreetmap.org/wiki/User:Surgical21/Key:access_JP )にあ ります。 ご意見お願いします。 道路交通法よく知らないのですが、 シニアカーはどこに入るのでしょう? ribbon ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-us] For comment: import of amenity=bicycle_repair_stations
To summarize: a proposed import of of bicycle repair stations. The database is maintained by a vendor of bicycle repair stations, the data quality is spot on in many cases, and geocoding level in other cases with the pins generally in the right area. The stations are too small to find on an air photo, but frequently do appear in press releases than be found with a search engine. The vendor uses OSM as a base map: http://www.dero.com/fixitmap/fixitmap.html The discussion is on the imports list. The data is at: http://www.dero.com/fixitmap/fixitmap.html Discussion centers on how best to improve the inexact pin locations. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
