[OSM-talk] Attic data on Overpass API
Dear all, the attic feature of Overpass API should now work properly. An example how to use this feature is http://www.openstreetmap.org/user/ikonor/diary/23329 A big thank you to Ikonor at this point. In detail, the database has been rebuilt. I tried to do as much checks as possible, and this has shown further bugs, which in turn led me to fix this in the code and then re-build the database again. A thank you to Stephan and Markus who managed to obtain a temporary powerful server; this ultimately enabled to do the last database rebuild within less than a week. I will give details about the kind of bugs that kept me busy: To keep the database as small as possible (currently more than 400 GB are painful, compare this to 25 GB of a PBF planet file), we store attic data as delta to the next newer version. Unchanged details like not changed tags aren't stored at all. For example, the tags of node version=3 lat=50 lon=10 timestamp=2011-01-01 tag k=name v=something/ tag k=highway v=bus_stop/ tag k=bus v=yes/ tag k=FIXME v=check_name/ /node node version=4 lat=50 lon=10 timestamp=2012-01-01 tag k=name v=something else/ tag k=highway v=bus_stop/ tag k=bus v=yes/ tag k=shelter v=yes/ /node are stored as current: name = something else current: highway = bus_stop current: bus = yes current: shelter = yes attic: before 2012: name = something attic: before 2012: FIXME = check_name attic: before 2012: shelter = void This allows us to save space for the repeated tags highway and bus. The main traces of the bug were checksum disparities in five of the 6000 checked first augmented diffs, spanning roughly 12 September to 16 September 2012. In detail, the diffs generated from the database state as of 1st October 2012 (thus, representing deltas to the then-current state of 1st October 2012) were not consistent with the diffs generated for the same minutes based on deltas to the database state as of June 2014. A detailed re-generation of the augmented diffs of both database states has shown that an extra tag was present on the node 1700083447 in its attic state of September 2012 computed from June 2014 in comparison to the same node at the same attic state computed from the database as of October 2012. Do you have guessed what has gone wrong? Me not so far, so I had to understand the subtle details. There are millions of nodes carrying tags, so what is so special about this one? It turned out that the node has moved forth and back over a significant distance, see versions 11, 14, and 15. While the movement itself is not so large (about 2 km), it happened to change its quadtile index to a new value and then back to the old value. And in version 13, after the move forth, the tag is_capital=country has been added and not changed when the node moved back. I managed in the delta computation to set a marker on the quadtile index of the older position that the tag is present, but I forgot to set a marker on the new position that the tag isn't present on earlier versions on this quadtile index. Now: Why didn't this pop up earlier? Haven't there been tests? There have been tests, but obviously not enough, and you always only know afterwards which tests have been missing. The whole problem doesn't appear to a node when the node never existed at this place before (only 3 in a million of nodes ever get back to a quadtile index where they have been before). And it doesn't appear either when the tag had any value on this older node versions (so the total number of affected nodes is less than 100), because there is then a marker for this older version and this specific key. Both cases have been tested individually, but not both together. In total: I've worked to get the number of bugs down, and I'm confident to call the database state now consistent, but there might be other arcane bugs that affect only few objects in specific versions. So please be bold to report suspect query results to me, but be also bold in using the new attic database. Cheers, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Achavi + WhoDidIt
Hi! Roland, thanks for Overpass attic feature, and thanks to Norbert for Achavi, especially for changeset visualizing feature. I've just added links to Achavi from WhoDidIt RSS feed and popups, so you can easily check what's been modified. Also there is a bookmarklet in this shtosm article: http://shtosm.ru/all/noveyshaya-istoriya/ (look for Changeset in the last passage). It would redirect you to Achavi from a changeset browsing page on osm.org. IZ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Attic data on Overpass API
Roland this is awesome. Your presentation at SOTM was quite interesting and I was waiting for the revision of the database. Below is an example where I extract places for Sierra Leone, with diff from 15-03 to 02-07. This work nicely. [adiff:2014-03-15T00:00:00Z,2014-07-02T24:00:00Z];((area[name=Sierra Leone];);node[place](area);;);out meta geom; This worked nicely. Tried to go further, extracting all diff nodes between 03-15 and 02-07 for Sierra Leone. This worked well exporting as Raw Data from Overpass API (116 meg output), but I receive this Ajax error message trying to run in the browser, probably because of the size of the output: Ajax Error - An error occured during the execution of the overpass query! Request rejected. (e.g. server not found, request blocked by browser addon, request redirected, internal server errors, etc.) Error while parsing the data (parsererror). [adiff:2014-03-15T00:00:00Z,2014-07-02T24:00:00Z];((area[name=Sierra Leone];);node(area);;);out meta geom; My next step will be to learn how to extract simultaneously various objects (ie. node, way, relation). Thanks again for this awesome work. Pierre De : Roland Olbricht roland.olbri...@gmx.de À : osm-talk talk@openstreetmap.org Envoyé le : Samedi 2 août 2014 2h27 Objet : [OSM-talk] Attic data on Overpass API Dear all, the attic feature of Overpass API should now work properly. An example how to use this feature is http://www.openstreetmap.org/user/ikonor/diary/23329 A big thank you to Ikonor at this point. In detail, the database has been rebuilt. I tried to do as much checks as possible, and this has shown further bugs, which in turn led me to fix this in the code and then re-build the database again. A thank you to Stephan and Markus who managed to obtain a temporary powerful server; this ultimately enabled to do the last database rebuild within less than a week. I will give details about the kind of bugs that kept me busy: To keep the database as small as possible (currently more than 400 GB are painful, compare this to 25 GB of a PBF planet file), we store attic data as delta to the next newer version. Unchanged details like not changed tags aren't stored at all. For example, the tags of node version=3 lat=50 lon=10 timestamp=2011-01-01 tag k=name v=something/ tag k=highway v=bus_stop/ tag k=bus v=yes/ tag k=FIXME v=check_name/ /node node version=4 lat=50 lon=10 timestamp=2012-01-01 tag k=name v=something else/ tag k=highway v=bus_stop/ tag k=bus v=yes/ tag k=shelter v=yes/ /node are stored as current: name = something else current: highway = bus_stop current: bus = yes current: shelter = yes attic: before 2012: name = something attic: before 2012: FIXME = check_name attic: before 2012: shelter = void This allows us to save space for the repeated tags highway and bus. The main traces of the bug were checksum disparities in five of the 6000 checked first augmented diffs, spanning roughly 12 September to 16 September 2012. In detail, the diffs generated from the database state as of 1st October 2012 (thus, representing deltas to the then-current state of 1st October 2012) were not consistent with the diffs generated for the same minutes based on deltas to the database state as of June 2014. A detailed re-generation of the augmented diffs of both database states has shown that an extra tag was present on the node 1700083447 in its attic state of September 2012 computed from June 2014 in comparison to the same node at the same attic state computed from the database as of October 2012. Do you have guessed what has gone wrong? Me not so far, so I had to understand the subtle details. There are millions of nodes carrying tags, so what is so special about this one? It turned out that the node has moved forth and back over a significant distance, see versions 11, 14, and 15. While the movement itself is not so large (about 2 km), it happened to change its quadtile index to a new value and then back to the old value. And in version 13, after the move forth, the tag is_capital=country has been added and not changed when the node moved back. I managed in the delta computation to set a marker on the quadtile index of the older position that the tag is present, but I forgot to set a marker on the new position that the tag isn't present on earlier versions on this quadtile index. Now: Why didn't this pop up earlier? Haven't there been tests? There have been tests, but obviously not enough, and you always only know afterwards which tests have been missing. The whole problem doesn't appear to a node when the node never existed at this place before (only 3 in a million of nodes ever get back to a quadtile index where they have been before). And it doesn't appear either when the tag had any value on this older node versions (so the total number of affected nodes is less than 100), because there is then a
Re: [OSM-talk] Using Notes in France
On 30/07/2014, Pieren pier...@gmail.com wrote: On Wed, Jul 30, 2014 at 12:34 AM, Paul Norman penor...@mac.com wrote: I'd consider that a useful note, and certainly within the scope of what notes were intended for. ?! useful in what ? That the street names are missing in a town ? Then create a note for missing addresses, shops, pharmacies, etc. Such notes do not help contributors because it is so obvious and does not bring any information or error report helping the others. Especially for missing street names, where we have plenty of good tools to find unnamed highways worldwide. Any FOO needs fixing here note that just repeats what QA tools automatically point out is just wasting contributors' time. It's excusable if comming from an OSM newbie, but contributors ought to know better. There are (as always) exceptions. One I know of is a case of mapper-commenter collaboration in Northern Ireland where the mapper opened many notes of the type what is this called ? and a local commenter would answer, then the mapper would edit the map and close the notes. It's only advisable if you know a specific someone will read and answer your notes. I'd say notes as todo lists are ok in some circumstances, such as reminding about a recent/future construction end date, or as a quick survey note-taking tool (which you'll close youself asap). I'm not a big fan of either, but they are reasonable. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] Comemoração de 10 anos do OSM
Olá, No dia 09 de agosto (próximo sábado) o OpenStreetMap completa 10 anos! http://wiki.openstreetmap.org/wiki/OpenStreetMap_10th_Anniversary_Birthday_party Seria legal ter eventos de comemoração ou pelo menos uma mapatona online... quem se anima? Galera de Brasília, estou indo morar aí a partir de amanhã, podemos marcar uma comemoração presencial! abraços, wille ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Comemoração de 10 anos do OSM
Eu quero um meetup ou similar no Espírito Santo - Algum que interessa? Vitória, Vila Velha, Guarapari? Aun Johnsen On Aug 2, 2014, at 18:21, Wille wi...@wille.blog.br wrote: Olá, No dia 09 de agosto (próximo sábado) o OpenStreetMap completa 10 anos! http://wiki.openstreetmap.org/wiki/OpenStreetMap_10th_Anniversary_Birthday_party Seria legal ter eventos de comemoração ou pelo menos uma mapatona online... quem se anima? Galera de Brasília, estou indo morar aí a partir de amanhã, podemos marcar uma comemoração presencial! abraços, wille ___ 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: [Talk-br] Reversão Itabira - MG
De vez em quando eu falo com o naoliv sobre coisas aleatórias, mas nunca entro no irc... :-P Em 2 de agosto de 2014 22:27, Tarcisio Oliveira tarci...@ymail.com escreveu: Se eu não me engano, o naoliv e o jgpaker estão fazendo essa análise, vira e mexe eles falam disso no canal #osm-br Em 02-08-2014 22:19, John Packer escreveu: Paulo, Lembro que um tempo atrás soubemos de um grupo do Tracksource que os dados importados pelo Genulpho não são do mesmo. Se eu não me engano, o Genulpho pegou os dados com outro desenvolvedor, mas não pediu permissão para importar para o OSM. Reforçando: A questão aqui não é se esta importação deveria ser revertida ou não. O problema é saber quais conjuntos de alterações devem ser revertidos e quais não, pois o Genulpho adicionou e removeu vários objetos relacionados com a importação em outros conjuntos de alteração e só reverter os conjuntos de alteração onde foi feita as adições em massa não é o suficiente. Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho, mas creio que a maioria não se sinta confortável com isso, já que ele faz outras contribuições. Em 2 de agosto de 2014 18:34, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pessoal, Lembrem que os dados do Tracksource não são disponíveis para download (closed source). Ele só poderia usar os dados do Tracksource caso ele tenha sido desenvolvedor do mapa em questão no Projeto. Temos que usar a lógica antes de formular hipóteses, sobretudo aquelas que comprometem a reputação de um colega. Os mapas que ele mesmo criou evidentemente pode compartilhar se suas fontes forem compatíveis com o OSM. Agora concordo que vias duplicadas são lixo que deve ser revertido. []s PC Em 30 de julho de 2014 20:36, Tarcisio Oliveira tarci...@ymail.com escreveu: *Como citei anteriormente, na minha opinião, se um usuário faz uma importação dessa forma, descumprindo todas recomendações e nem se dá o luxo de verificar o resultado da importação, não merece que aquele trabalho, mesmo que tenha algo de útil nele, seja aprovado e mantido.* * * Concordo, se o usuário não se deu ao trabalho de abrir a região que acabou de modificar, e notar que causou um estrago, no mais deve ser notoficado que fez coisa errada e o changeset revertido. Em 30-07-2014 17:33, thunder...@gpsinfo.com.br escreveu: A minha duvida do porque não se reverte está concentrado para o município de Itabira - MG onde, pelo conjunto de alterações http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170 , importou os dados sobre os dados existentes duplicando quase toda a cidade de Itabira - MG. Como citei anteriormente, na minha opinião, se um usuário faz uma importação dessa forma, descumprindo todas recomendações e nem se dá o luxo de verificar o resultado da importação, não merece que aquele trabalho, mesmo que tenha algo de útil nele, seja aprovado e mantido. Se ele quer ajudar que assim seja, mas não destrua o trabalho dos demais. Na minha opinião é reversão imediata e envio de mensagem a ele informando que importe novamente, mas cumprindo as recomendações para isso e verificando se o resultado da importação causou danos ao trabalhos dos demais. Perdoem, mas minha formação e educação militar me fez, por vezes, ser mais rígido e severo quando do descumprimento de normas e recomendações. -Mensagem Original- From: Nelson A. de Oliveira Sent: Wednesday, July 30, 2014 3:02 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Reversão Itabira - MG Para quem quiser olhar os changesets do Genulpho: http://naoliv.iq.unesp.br/osm/genulpho/ Os links dos changesets são para o OSMHV (então a primeira vez que acessar pode ter uma página em branco ou dizendo que está na fila; é só atualizar o endereço depois) Os que ele editou com o JOSM eu destaquei (porque muito provavelmente foram importações). Também precisa verificar todos os changesets onde há dados apagados, porque mesmo depois de parar com as importações, ainda tem edições onde ele apaga dados antigos de outros usuários (por exemplo, http://osm.mapki.com/history/way.php?id=288678930, apagado no começo do mês) Acho que isso deve dar uma noção da dificuldade e responder uma parte das dúvidas sobre porque não reverte as coisas dele? ___ 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: [Talk-br] Reversão Itabira - MG
Foi mau jgpaker, eu quis escrever Skippern. (bem diferente até) Em 02-08-2014 23:10, John Packer escreveu: De vez em quando eu falo com o naoliv sobre coisas aleatórias, mas nunca entro no irc... :-P Em 2 de agosto de 2014 22:27, Tarcisio Oliveira tarci...@ymail.com mailto:tarci...@ymail.com escreveu: Se eu não me engano, o naoliv e o jgpaker estão fazendo essa análise, vira e mexe eles falam disso no canal #osm-br Em 02-08-2014 22:19, John Packer escreveu: Paulo, Lembro que um tempo atrás soubemos de um grupo do Tracksource que os dados importados pelo Genulpho não são do mesmo. Se eu não me engano, o Genulpho pegou os dados com outro desenvolvedor, mas não pediu permissão para importar para o OSM. Reforçando: A questão aqui não é se esta importação deveria ser revertida ou não. O problema é saber quais conjuntos de alterações devem ser revertidos e quais não, pois o Genulpho adicionou e removeu vários objetos relacionados com a importação em outros conjuntos de alteração e só reverter os conjuntos de alteração onde foi feita as adições em massa não é o suficiente. Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho, mas creio que a maioria não se sinta confortável com isso, já que ele faz outras contribuições. Em 2 de agosto de 2014 18:34, Paulo Carvalho paulo.r.m.carva...@gmail.com mailto:paulo.r.m.carva...@gmail.com escreveu: Pessoal, Lembrem que os dados do Tracksource não são disponíveis para download (closed source). Ele só poderia usar os dados do Tracksource caso ele tenha sido desenvolvedor do mapa em questão no Projeto. Temos que usar a lógica antes de formular hipóteses, sobretudo aquelas que comprometem a reputação de um colega. Os mapas que ele mesmo criou evidentemente pode compartilhar se suas fontes forem compatíveis com o OSM. Agora concordo que vias duplicadas são lixo que deve ser revertido. []s PC Em 30 de julho de 2014 20:36, Tarcisio Oliveira tarci...@ymail.com mailto:tarci...@ymail.com escreveu: /Como citei anteriormente, na minha opinião, se um usuário faz uma importação dessa forma, descumprindo todas recomendações e nem se dá o luxo de verificar o resultado da importação, não merece que aquele trabalho, mesmo que tenha algo de útil nele, seja aprovado e mantido.// / Concordo, se o usuário não se deu ao trabalho de abrir a região que acabou de modificar, e notar que causou um estrago, no mais deve ser notoficado que fez coisa errada e o changeset revertido. Em 30-07-2014 17:33, thunder...@gpsinfo.com.br mailto:thunder...@gpsinfo.com.br escreveu: A minha duvida do porque não se reverte está concentrado para o município de Itabira - MG onde, pelo conjunto de alterações http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170 , importou os dados sobre os dados existentes duplicando quase toda a cidade de Itabira - MG. Como citei anteriormente, na minha opinião, se um usuário faz uma importação dessa forma, descumprindo todas recomendações e nem se dá o luxo de verificar o resultado da importação, não merece que aquele trabalho, mesmo que tenha algo de útil nele, seja aprovado e mantido. Se ele quer ajudar que assim seja, mas não destrua o trabalho dos demais. Na minha opinião é reversão imediata e envio de mensagem a ele informando que importe novamente, mas cumprindo as recomendações para isso e verificando se o resultado da importação causou danos ao trabalhos dos demais. Perdoem, mas minha formação e educação militar me fez, por vezes, ser mais rígido e severo quando do descumprimento de normas e recomendações. -Mensagem Original- From: Nelson A. de Oliveira Sent: Wednesday, July 30, 2014 3:02 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Reversão Itabira - MG Para quem quiser olhar os changesets do Genulpho: http://naoliv.iq.unesp.br/osm/genulpho/ Os links dos changesets são para o OSMHV (então a primeira vez que acessar pode ter uma página em branco ou dizendo que está na fila; é só atualizar o endereço depois) Os que ele editou com o JOSM eu destaquei (porque muito provavelmente foram importações). Também precisa verificar todos os changesets onde há dados apagados, porque mesmo depois de parar com
Re: [Talk-br] Reversão Itabira - MG
Amigos, quanto a Itabira – MG passei o dia todo de hoje editando no mapa aquela cidade, Acredito que já consegui corrigir uns 80% do estrago causado pelo Genulpho no mapa de Itabira. Não tenho duvida que ali ele importou dados do Tracksource. Cito isso porque tenho bastante experiência em edições dentro de padrões Tracksource e nessas correções que venho fazendo do estrago dele em Itabira identifico técnicas empregadas no Tracksource. Por exemplo: No Tracksource, para não fazer “looping”, um desenho de rotatória deve ser particionado de forma que fique duas meia lua. Ele colocou assim em todas as rotatórias inseridas na cidade. No tracksource se coloca na via POI de Lombada nomeado assim e se empregando a técnica de 30m para um dos lados quando pista dupla. Excluí um monte deles. No Tracksource se nomeia os acessos, rampa, rotatória, agulhas, etc. Ele nomeou tudo no mapa. etc. etc etc.. Como solicitei a reversão e ficam só debatendo sem solução, decidi editar o mapa e analisar manualmente os erros nele e corrigi-los. Como falta pouco para terminar julgo que até a semana que vem termino. []s Marcio From: John Packer Sent: Saturday, August 2, 2014 10:19 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Reversão Itabira - MG Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho, mas creio que a maioria não se sinta confortável com isso, já que ele faz outras contribuições. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Eigenen kartenausschnitt auf server.
Am 01.08.2014 um 23:09 schrieb Michael Rohweder: .. Ich möchte auf basis der aktuellsten OSM karten, die ich auch selber mit aktualisieren werde, in einem Stadtplan eigene Gebiete eintragen. Diese sollten am besten nur für mich und ausgewählte zu sehen sein. Des weiteren möchte ich auch nur ein Gebiet hervorheben können und ggf Druckansichten daraus generieren. Einen Tile server habe ich testweise schon erstellt, doch müsste ich da noch den richtigen Kartenausschnitt eintragen oder halt meine Gebiete über die normale Karte drüber legen können. Wenn möglich das ganze dann auch noch einfach zu bearbeiten. Also Kartenbearbeitung über openstreetmap.de per json und Bearbeitung meiner Gebiete per ??? eigenem ?? Server der als Hintergrund die OSM karte hat?? .. Michael Hallo Michael, willkommen in der Welt des GIS ... ... und ausgewählte äääh, des Web-GIS. Schau dir mal die folgenden Programme an: QGIS - Als Desktop-Programm zum Erfassen PostgreSQL/PostGIS-Datenbank zum Speichern deiner Geometrien Einen Tile server habe ich testweise schon erstellt, OSM (Kacheln) können als Hintergrund-Karte dargestellt werden. Deine Daten und OSM wären getrennte Layer. Somit bräuchtest du für OSM keinen eigenen Kachelserver aufsetzen. Das Zusammenfügen der Layer erfolgt im Client. Du könntest also die Kacheln vom OSM-Server einbinden. in einem Stadtplan eigene Gebiete eintragen. Das ist somit falsch ausgedrückt. Das bleibt getrennt. Wenn auch andere darauf zugreifen sollen, musst du deine Daten als Service publizieren. Als Alternative zu Kacheln bietet sich WMS an. WMS = Web Map Service Programme für WMS: Mapserver, Geoserver, QGIS-Server Als Client fürs Web: Openlayers. Faustregel: - Viele Nutzer und einheitliches Kartenbild - Kacheln, Tileserver (wie OSM, Google-Maps) - Wenige Nutzer, beliebige Kombination von Layern abrufbar - WMS Kacheln werden vorproduziert. WMS rendert jeden Aufruf einzeln. Beispiel: http://map.krz.de/cms/cms2mapu.php?id=670 OSM oder Luftbild = Hintergrundkarte Wohnbaulücken = eigene Daten darüber In diesem Fall sind die OSM-Daten allerdings aber auch ein eigener WMS, keine Kacheln. Grund: Der Client Mapbender kann nur WMS, keine Kacheln. Frank ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Drupal - Karte einbinden
Hallo, Am 01.08.2014 07:48, schrieb Markus: hier gibt es eine Doku, wie man Karten in Drupal einbindenn kann: http://wiki.openseamap.org/wiki/De:OpenSeaMap_in_Website#Drupal En Benutzer meldet, dass das nicht funktioniere... Vielleicht kann das jemand prüfen/verbessern? Ich nutze das Modul MappingKit seit langem unter Drupal 6, Beispiel: [1]. Das Modul funktioniert unter Drupal 6 sehr gut, man kann zwischen einigen vordefinierten Tile-Servern wählen (osm.org, Google Maps/Satellite) und GPX-Tracks und -Waypoints anzeigen. Für einfache Anwendungsfälle ist es ausreichend und auch einfach zu bedienen. Leider wird das Modul nicht mehr gepflegt und es ist daher auch nicht für die aktuelle Drupal-Version 7 verfügbar. Grüße Rainer [1] http://blog.velocarte66.fr/de/node/295 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Carta tecnica Comune di Lecce
Il giorno 01/ago/2014, alle ore 14:09, Leonardo kinetocor...@gmail.com ha scritto: Non ci sono neanche proposal per definire bene le reti telefoniche di un paese (piloni, centraline, ecc...). qualche proposta ci sta, ma probabilmente non copre tutto. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Carta tecnica Comune di Lecce
Mi puoi linkare la pagina che butto un'occhiata? Grazie! Il 02/ago/2014 10:19 Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Il giorno 01/ago/2014, alle ore 14:09, Leonardo kinetocor...@gmail.com ha scritto: Non ci sono neanche proposal per definire bene le reti telefoniche di un paese (piloni, centraline, ecc...). qualche proposta ci sta, ma probabilmente non copre tutto. ciao, Martin ___ 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: [Talk-it] Errori riscontrati nei confini comunali
Il confine tra Cuceglio e Agliè era stato traslato rispetto ai dati Istat 2011, ho cancellato e ripristinato dai dati Istat originali. Grazie per le segnalazioni. Ciao, Alberto From: Lorenzo Beba Beltrami [mailto:lorenzo.b...@gmail.com] Sent: venerdì 1 agosto 2014 16:01 To: openstreetmap list - italiano Subject: Re: [Talk-it] Errori riscontrati nei confini comunali Piemonte: relation: 44800 Cuceglio (la way di confine passa su se stessa) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] sentiero non percorribile con gpsies.com (gruppo del Carega - VR)
Ciao a tutti, stavo cercando di creare una rotta nel gruppo del carega (provincia di Verona al confine con Trento e Vicenza) e il sentiero 283 viene visualizzato ma non è percorribile con l'opzione segui strade graphHopper. https://www.openstreetmap.org/way/138700874 Ho provato a guardarlo con l'editor OSM per vedere se era disconnesso ma sembra di no però ammetto di essere assolutamente noob ;) Ho provato a cambiare un attributo ma non è cambiato nulla. Spero di non aver fatto danni. Tra l'altro mi sono accorto di una discontinuità di quota sul sentiero 185 https://www.openstreetmap.org/way/208428704 Domani spero di riuscire a mapparlo in modo da aggiustarlo. grazie alberto ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Bibliotecari] opendata anagrafe biblioteche
Tempo fa erano stati segnalati questi punti. Ne avevo controllato qualcuno, ma le coords erano piuttosto imprecise. Se fossero sempre loro potrebbero essere comunque utili per arricchire l'eventuale biblioteca nei pressi di e-mail, tel fax sito ecc -- cascafico.altervista.org twitter.com/cascafico Il 01/ago/2014 21:12 Federico Leva (Nemo) nemow...@gmail.com ha scritto: raffaele messuti, 24/07/2014 17:25: https://twitter.com/iccu2/status/492327684857659392 http://anagrafe.iccu.sbn.it/opencms/opencms/open_data/ applausi per iccu. non ho controllato nulla del contenuto, ma sono contento lo stesso. adesso servono solo delle idee per farci delle applicazioni sopra. Dato che ci sono dati anagrafici e territoriali (CSV): dati anagrafici, territoriali e coordinate geografiche, è tutta roba importabile in automatico su OpenStreetMap, no? Con anche associati contatti (XML): tutti i contatti, anche più valori per ogni tipo (email, telefoni, fax, url etc...) ed eventualmente tipologie (CSV): tipologie amministrative e tipologie funzionali delle biblioteche se ci sono campi per questo in OSM. Nemo ___ 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] Fwd: Re: [Bibliotecari] opendata anagrafe biblioteche
Messaggio originale Oggetto:Re: [Bibliotecari] [Talk-it] opendata anagrafe biblioteche Data: Sat, 2 Aug 2014 10:05:55 +0200 Mittente: Luca Martinelli Il 02/ago/2014 09:01 sabas88 ha scritto: Quando avevo importato le biblioteche liguri dai dati della regione avevo conservato due codici di riferimento, sai mica cosa sono? (dal punto di vista biblioteche) Il codice ISIL è stabile? Il codice ISIL è stabile. à un codice internazionale che identifica le biblioteche. L. ___ Bibliotecari mailing list Invio messaggi in lista: bibliotec...@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] sentiero non percorribile con gpsies.com (gruppo del Carega - VR)
...il 283 così com'è è a posto ...tant'è vero che su basecamp funziona alla grande ... ...il185 è stato sicuramente manomesso da qualcuno.oltretutto fa parte del sentiero europeo E5...se qualcuno ha le tracce potrebbe metterlo a posto???l'ultimo a metterci mano è stato brizzo85ma nella stessa zona c'è parecchia confusione con la presenza di molte multipoligoni... -- View this message in context: http://gis.19327.n5.nabble.com/sentiero-non-percorribile-con-gpsies-com-gruppo-del-Carega-VR-tp5813454p5813471.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-it] sentiero non percorribile con gpsies.com (gruppo del Carega - VR)
Il giorno sab, 02/08/2014 alle 14.53 +0200, Alberto Valente ha scritto: Ciao a tutti, stavo cercando di creare una rotta nel gruppo del carega (provincia di Verona al confine con Trento e Vicenza) e il sentiero 283 viene visualizzato ma non è percorribile con l'opzione segui strade graphHopper. https://www.openstreetmap.org/way/138700874 Ho provato a guardarlo con l'editor OSM per vedere se era disconnesso ma sembra di no però ammetto di essere assolutamente noob ;) Ho provato a cambiare un attributo ma non è cambiato nulla. Spero di non aver fatto danni. Tra l'altro mi sono accorto di una discontinuità di quota sul sentiero 185 https://www.openstreetmap.org/way/208428704 Domani spero di riuscire a mapparlo in modo da aggiustarlo. grazie alberto Forse il problema era quel sac_scale=hiking_biking. Ho notato che anche su altri percorsi che ce l'avevano il routing non funziona con graphhopper. Adesso li ho corretti tutti, bisogna aspettare che aggiornino i dati ma non vedo ogni quanto lo fanno Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Bibliotecari] opendata anagrafe biblioteche
Posso confermare che hanno dei problemi di coordinate. Su due a me noti: IT-UD0082 ha un errore di circa 1700 metri. IT-UD0016 ha un errore di circa 30 metri (collocandola in altro edificio). Il giorno 02 agosto 2014 15:42, Cascafico Giovanni cascaf...@gmail.com ha scritto: Tempo fa erano stati segnalati questi punti. Ne avevo controllato qualcuno, ma le coords erano piuttosto imprecise. Se fossero sempre loro potrebbero essere comunque utili per arricchire l'eventuale biblioteca nei pressi di e-mail, tel fax sito ecc -- cascafico.altervista.org twitter.com/cascafico Il 01/ago/2014 21:12 Federico Leva (Nemo) nemow...@gmail.com ha scritto: raffaele messuti, 24/07/2014 17:25: https://twitter.com/iccu2/status/492327684857659392 http://anagrafe.iccu.sbn.it/opencms/opencms/open_data/ applausi per iccu. non ho controllato nulla del contenuto, ma sono contento lo stesso. adesso servono solo delle idee per farci delle applicazioni sopra. Dato che ci sono dati anagrafici e territoriali (CSV): dati anagrafici, territoriali e coordinate geografiche, è tutta roba importabile in automatico su OpenStreetMap, no? Con anche associati contatti (XML): tutti i contatti, anche più valori per ogni tipo (email, telefoni, fax, url etc...) ed eventualmente tipologie (CSV): tipologie amministrative e tipologie funzionali delle biblioteche se ci sono campi per questo in OSM. Nemo ___ 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] Relation non chiusa
Buona sera Volevo chiedervi qual'è sia l'approccio migliore e il tool da utilizzare ( josm, web o altro ) per poter analizzare un set di dati e capire in quale Gruppo di modifiche sono state effettuate dei cambiamenti. Nel caso specifico ho notato che questa relation http://www.openstreetmap.org/relation/2054914 non risulta essere chiusa perchè mancante di una o più way però non so destreggiarmi con i gruppi di modiche per capire quando queste elementi sono stati eventualmente eliminati, sempre che la Relation non sia stata creata così per qualche motivo che mi sfugge. Vi ringrazio Tommaso ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-gb-westmidlands] Aug 9th OSM 10th Birthday
On 17 July 2014 15:52, Brian Prangle br...@mappa-mercia.org wrote: 6/8 Kafé Sorry I shan't be joining you; I shall be at Wikimania in London, where I am giving a talk on OSM in a Wikimedia context: https://wikimania2014.wikimedia.org/wiki/Submissions/OpenStreetMap_-_what_is_it_and_what_does_it_mean_for_Wikimedians%3F and I hope to take part in the joint Wikimania/OSM birthday event there. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-bf] Présentations OSM lors de la mission EOF
Bonjour à tous, J'ai (enfin) mis en ligne mes présentations sur mon compte Slideshare http://www.slideshare.net/Sev_hotosm/, la longue et celle courte (sans doute à retravailler) qui décrit les trois échelles de cartographie à prendre en compte. Bien cordialement, Séverin ___ Talk-bf mailing list Talk-bf@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-bf
Re: [Talk-cz] zna?en? trasy a K?T
Ahoj! PS: Kdyby to někoho zajímalo hlouběji - programátorsky či turisticky, a byl ochoten něco dělat (procházet trasy v terénu, procházet je na mapě podle dat, experimentovat s prográmky), tak se ozvěte. Turisticky trasy me zajimaj, kdyz nekde jdu tak mapuju, ale jestli se neco da udelat i od pocitace...? Jakub A. Tesinsky (j...@kub.cz) Aragorn? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Tracer - pLPIS
Ahoj, takže mám skoro dokončenou první verzi. Co to umí: umí získat geometrii a kulturu prvku a následně vytvořit cestu nebo multipolygon (pokud existují nějaké vnitřní prvky) a otagovat. Co to neumí: napojení na sousední pole (pokud se dané pole dotýkají), neřeší se konflikty, nekontroluje se existence daného objektu a zatím má každý modul samostatnou klávesovou zkratku. Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto drobnosti a) Mapování - to mám zatím takto: *orná půda:* landuse: farmland *chmelnice:* landuse: farmland; crop: hop *vinice:* landuse: vineyard *ovocný sad*: landuse: orchard *travní porost:* landuse: meadow *porost RRD:* landuse: forest *zalesněná půda:* landuse, forest *rybník:* landuse: reservoir *jiná kultura:* landuse: farmland *jiná kultura (školka):* landuse: plant_nursery *jiná kultura (zelinářská zahrada):* landuse: farmland; crop: vegetables Bohužel si nejsem vůbec jistý, že vše dostanu přesně tak jak je to napsáno výše. Už jsem narazil u zalesněno a zalesněná půda. Bohužel nevím, kde by se daly otestovat speciální případy. b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura. Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy ) navrhuji source=eagri:plpis (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian) Mám taky nastavit pole *(p)lpis:kultura*? A co pole *kultura_od* namapovaná třeba na *start_date* ? Co myslíte? Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
Je fais une proposition de nouveau format pour le fichier des noms de lieux-dits générés depuis le cadastre, voir un exemple ici: http://dl.free.fr/bOdG4FdS9 Les différences par rapport à avant: - fichier zip à part - tag place= laissé vide - plus de fixme - fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm - LISEZ-MOI.txt - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui contient juste des limites (un multipolygon par lieu-dit), je pense que c'est utile pour évaluer le nombre de maisons et donc remplir le tag place correctement (enfin pour ceux qui arrivent à comprendre le tag place...) J'attends vos commentaires avant de potentiellement rendre ça dispo sur cadastre.openstreetmap.fr Le 29 juillet 2014 13:38, Pieren pier...@gmail.com a écrit : 2014-07-29 9:18 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Ce n'est pas tant le problème du tag fixme généré automatiquement, en fait il est bien pratique pour repérer/retrouver les imports fait en aveugle. Le véritable problème est bien l'envoi tel quel de données brutes qui ont besoin d'être revues et améliorées au préalable et qui ne l'on pas été. Je pense qu'il faudrait recontacter les auteurs de ces fixme et leur demander ce qu'ils comptent faire. Sans réponse après quelques jours : revert. S'ils disent qu'ils n'ont pas le temps ou laissent le job a d'autres : revert. En fait, ne garder que ceux qui s'engagent à nettoyer leur(s) commune(s) dans un délai raisonnable. Au delà des cas déjà présents, je ne voie pas d'inconvénient à remettre en ligne ce genre d'extractions avec des fixme à condition de bien avertir les gens qu'ils doivent nettoyer les fixme avant upload et de mieux surveiller leur apparition éventuelle dans la base (avec un revert plus rapide si les gens ne respectent pas la procédure) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
vdct travaille aussi sur le sujet des lieux-dits côté BANO. Vérifiez que vous ne faite pas les choses en double et avec un résultat différent. Un peu d'harmonie dans ce monde de données brutes ;) Le 2 août 2014 15:13, Tyndare tynd...@wanadoo.fr a écrit : Je fais une proposition de nouveau format pour le fichier des noms de lieux-dits générés depuis le cadastre, voir un exemple ici: http://dl.free.fr/bOdG4FdS9 Les différences par rapport à avant: - fichier zip à part - tag place= laissé vide - plus de fixme - fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm - LISEZ-MOI.txt - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui contient juste des limites (un multipolygon par lieu-dit), je pense que c'est utile pour évaluer le nombre de maisons et donc remplir le tag place correctement (enfin pour ceux qui arrivent à comprendre le tag place...) J'attends vos commentaires avant de potentiellement rendre ça dispo sur cadastre.openstreetmap.fr Le 29 juillet 2014 13:38, Pieren pier...@gmail.com a écrit : 2014-07-29 9:18 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Ce n'est pas tant le problème du tag fixme généré automatiquement, en fait il est bien pratique pour repérer/retrouver les imports fait en aveugle. Le véritable problème est bien l'envoi tel quel de données brutes qui ont besoin d'être revues et améliorées au préalable et qui ne l'on pas été. Je pense qu'il faudrait recontacter les auteurs de ces fixme et leur demander ce qu'ils comptent faire. Sans réponse après quelques jours : revert. S'ils disent qu'ils n'ont pas le temps ou laissent le job a d'autres : revert. En fait, ne garder que ceux qui s'engagent à nettoyer leur(s) commune(s) dans un délai raisonnable. Au delà des cas déjà présents, je ne voie pas d'inconvénient à remettre en ligne ce genre d'extractions avec des fixme à condition de bien avertir les gens qu'ils doivent nettoyer les fixme avant upload et de mieux surveiller leur apparition éventuelle dans la base (avec un revert plus rapide si les gens ne respectent pas la procédure) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
De : Christian Quest vdct travaille aussi sur le sujet des lieux-dits côté BANO. Vérifiez que vous ne faite pas les choses en double et avec un résultat différent. Un peu d'harmonie dans ce monde de données brutes ;) Le 2 août 2014 15:13, Tyndare a écrit : Je fais une proposition de nouveau format pour le fichier des noms de lieux-dits générés depuis le cadastre, voir un exemple ici: http://dl.free.fr/bOdG4FdS9 Les différences par rapport à avant: - fichier zip à part - tag place= laissé vide - plus de fixme - fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm - LISEZ-MOI.txt - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui contient juste des limites (un multipolygon par lieu-dit), je pense que c'est utile pour évaluer le nombre de maisons et donc remplir le tag place correctement (enfin pour ceux qui arrivent à comprendre le tag place...) J'attends vos commentaires avant de potentiellement rendre ça dispo sur cadastre.openstreetmap.fr Sur les lieux-dits, il y a de quoi faire pour 2 :) De mon côté je n'ai rien fait de concurrent, juste avancé (mais pas encore terminé) sur le sujet des suffixes de noms de voies qui parfois forment un hameau. J'aurai plus de temps après mi-août pour terminer. Pour la proposition de Tyndare, je trouve que ça va tout à fait dans le bon sens. J'ai 2 remarques : - je me demande si, dès lors qu'on veut éviter que certaines données soient envoyées, on ne gagnerait pas à directement en faire un layer raster, plutôt qu'un format .osm toujours sujet à boulettes ? Ceci pour les emprises des lieux-dits. - concernant les fichiers ponctuels de lieux-dits, j'enlèverais carrément le tag place plutôt que vide car JOSM le prend comme tel, et on a donc le risque de remplir la base avec une valeur 'vide' malheureuse. Sachant que un point avec juste un name=* sans autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus, ça donne une motivation pour explicitement en rajouter un. vincent ps. gazette Bano : les rapprochements OSM-cadastre dépassent 621K voies et les adresses dans OSM culminent à 2.19M, ça avance ! http://munin.openstreetmap.fr/bano-day.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])
Le samedi 2 août 2014 15:13:48, Tyndare a écrit : Je fais une proposition de nouveau format pour le fichier des noms de lieux-dits générés depuis le cadastre, voir un exemple ici: http://dl.free.fr/bOdG4FdS9 Note : dl.free.fr n'aime pas les bloqueurs de pubs, à désactiver si on veut le fichier. Les différences par rapport à avant: - fichier zip à part - tag place= laissé vide - plus de fixme - fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm - LISEZ-MOI.txt Je trouve ça très bien. On pourrait relancer la question du tag source sur les objets plutôt que le changeset, mais je dévierais hors sujet, ce qui mériterait un nouveau sujet. - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui contient juste des limites (un multipolygon par lieu-dit), je pense que c'est utile pour évaluer le nombre de maisons et donc remplir le tag place correctement (enfin pour ceux qui arrivent à comprendre le tag place...) Miam... ça me semble avoir plus de potentiel que ça, quand je vois un bois, ça me semble tout à fait adapté à du surfacique. Je pousserais même à dire que de nombreux villages pourraient (aussi) être uploadé en surfacique. Le risque étant qu'il se trouvera bien un gus pour nous uploader ce fichier sans retouche malgré l'énorme NE_PAS_ENVOYER_SUR_OSM Ajout d'un tag bidon dans le but de plus facilement repérer les upload sauvages de ce fichier ? J'attends vos commentaires avant de potentiellement rendre ça dispo sur cadastre.openstreetmap.fr Le 29 juillet 2014 13:38, Pieren pier...@gmail.com a écrit : 2014-07-29 9:18 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Ce n'est pas tant le problème du tag fixme généré automatiquement, en fait il est bien pratique pour repérer/retrouver les imports fait en aveugle. Le véritable problème est bien l'envoi tel quel de données brutes qui ont besoin d'être revues et améliorées au préalable et qui ne l'on pas été. Je pense qu'il faudrait recontacter les auteurs de ces fixme et leur demander ce qu'ils comptent faire. Sans réponse après quelques jours : revert. S'ils disent qu'ils n'ont pas le temps ou laissent le job a d'autres : revert. En fait, ne garder que ceux qui s'engagent à nettoyer leur(s) commune(s) dans un délai raisonnable. Au delà des cas déjà présents, je ne voie pas d'inconvénient à remettre en ligne ce genre d'extractions avec des fixme à condition de bien avertir les gens qu'ils doivent nettoyer les fixme avant upload et de mieux surveiller leur apparition éventuelle dans la base (avec un revert plus rapide si les gens ne respectent pas la procédure) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])
Le samedi 2 août 2014 16:15:12, V de Chateau-Thierry a écrit : j'enlèverais carrément le tag place plutôt que vide car JOSM le prend comme tel, et on a donc le risque de remplir la base avec une valeur 'vide' malheureuse. Ce qui a l'avantage de le faire s'afficher tous les outils QA du qui le supporte donc de repérer l'import indélicat et sur le validateur JOSM (réduire les chances que l'upload soit fait). Sachant que un point avec juste un name=* sans autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus, ça donne une motivation pour explicitement en rajouter un. Le rendu d'osm.org ne devrait rien afficher si place est vide : https://github.com/gravitystorm/openstreetmap- carto/blob/master/project.mml#L1163 -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])
Le 2 août 2014 16:32, sly (sylvain letuffe) lis...@letuffe.org a écrit : - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui Miam... ça me semble avoir plus de potentiel que ça, quand je vois un bois, ça me semble tout à fait adapté à du surfacique. Je pousserais même à dire que de nombreux villages pourraient (aussi) être uploadé en surfacique. Sûrement mais il faudrait arriver simplifier correctement ce fichier, en l'état ce n'est pas utilisable. Le risque étant qu'il se trouvera bien un gus pour nous uploader ce fichier sans retouche malgré l'énorme NE_PAS_ENVOYER_SUR_OSM Ajout d'un tag bidon dans le but de plus facilement repérer les upload sauvages de ce fichier ? Tu veux dire un tag fixme ? ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre ( était [import lieux-dits (avec fixme)])
Le 2 août 2014 16:44, Christian Quest cqu...@openstreetmap.fr a écrit : D'ailleurs dans les fichiers .osm il est possible d'ajouter un champ qui indique à JOSM que c'est un fichier à ne pas importer en l'état... et qui affichera des alertes avant tout upload. Je l'ai mis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pont Mathilde Rouen : 2 étapes
Le 18 Août, sur la Rive droite (Nord) , la bretelle #solupont qui actuellement renvoie au Nord sur la RN28 au lieu d'accèder au pont est fermée Je n'ai pas posé la question pour la Rive Sud (la rampe renvoit sur le Boulevard de l'Europe) , mais on peut sans doute se caler idem. Le 26 Août, le pont rouvre. NB : #solupont c'est le tag twitter apparu quand le pont a brûlé ! -- Hugues P. GCS RRAMUHN ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
De : Tyndare Le 2 août 2014 16:15, V de Chateau-Thierry a écrit : - je me demande si, dès lors qu'on veut éviter que certaines données soient envoyées, on ne gagnerait pas à directement en faire un layer raster, plutôt qu'un format .osm toujours sujet à boulettes ? Ceci pour les emprises des lieux-dits. Je suis d'accord mais je te laisse t'occuper de ça car je n'ai aucune idée de comment faire des raster. Ça marche. Je vais collecter les parcelles du cadastre vectoriel France, via Bano, et je suis sûr que Christian se fera un plaisir de crayonner ça avec les bonnes couleurs pur qu'on ait un rendu donnant les limites des noms de parcelles, et les noms bien lisibles. On aura au passage une visu des limites de communes, et donc parfois des divergences de tracé entre cadastres mitoyens... J’espère quand même que personne n'osera envoyer sciemment un fichier nommé NE PAS ENVOYER et qui en plus affiche une fenêtre d'avertissement dans JOSM si on essaye quand même de le faire. C'est vrai que ça fait beaucoup :) - concernant les fichiers ponctuels de lieux-dits, j'enlèverais carrément le tag place plutôt que vide car JOSM le prend comme tel, et on a donc le risque de remplir la base avec une valeur 'vide' malheureuse. Sachant que un point avec juste un name=* sans autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus, ça donne une motivation pour explicitement en rajouter un. Là pas d'accord. En laissant place= JOSM affiche un avertissement de validation au moment de l'envoie des données Clé 'place' non valide - Attributs avec des valeurs vides Alors que sans le tag place JOSM ne bronche pas. Je trouve que ça limite grandement le risque d'oublier de préciser une valeur. Mouais. Un avertissement, ça s'ignore... Sur le principe, ça me chiffonne que la manière la plus simple (comprendre : la plus en aveugle) d'envoyer de la donnée soit avec une donnée bancale. Un name seul, ok, c'est pauvre, mais un tag vide, ben... par définition, ça n'a pas de valeur. M'enfin. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Site basé sur OSM qui dessine routes + ajoute POI + exporte en GPX ou KML?
Bonjour Je n'ai pas trouvé de site web qui permette de faire ça pour préparer une balade en vélo: 1. Dessiner sur le web un parcours sur une carte en suivant la route, et en permettant de tirer dessus pour obliger à passer ailleurs 2. Ajouter des POI 3. Exporter le tout en KML ou GPX Tests: - GM Classic (https://maps.google.com/maps/myplaces?dg=feature) ne permet pas d'ajouter des POI - GM New (https://www.google.fr/maps/preview/) ne permet pas de dessiner des routes - la version gratuite de RideWithGPS n'exporte pas les POI - Strava et PlotARoute ne sont pas mieux - je n'ai trouvé aucune solution gratuite basée sur OSM qui permette 1) de dessiner des routes en suivant la route, 2) permette d'ajouter des POI, et 3) export en KML ou GPX. Quelqu'un connait-il une solution autre que de payer pour la version payante de RideWithGPS? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Site-base-sur-OSM-qui-dessine-routes-ajoute-POI-exporte-en-GPX-ou-KML-tp5813488.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Site basé sur OSM qui dessine routes + ajoute POI + exporte en GPX ou KML?
Crée ta route sur OSRM (http://osrm.at), puis exporte-la en GPX. Ensuite importe dans uMap (http://umap.openstreetmap.fr), et édite-la. :) On 08/03/2014 12:38 AM, Shohreh wrote: Bonjour Je n'ai pas trouvé de site web qui permette de faire ça pour préparer une balade en vélo: 1. Dessiner sur le web un parcours sur une carte en suivant la route, et en permettant de tirer dessus pour obliger à passer ailleurs 2. Ajouter des POI 3. Exporter le tout en KML ou GPX Tests: - GM Classic (https://maps.google.com/maps/myplaces?dg=feature) ne permet pas d'ajouter des POI - GM New (https://www.google.fr/maps/preview/) ne permet pas de dessiner des routes - la version gratuite de RideWithGPS n'exporte pas les POI - Strava et PlotARoute ne sont pas mieux - je n'ai trouvé aucune solution gratuite basée sur OSM qui permette 1) de dessiner des routes en suivant la route, 2) permette d'ajouter des POI, et 3) export en KML ou GPX. Quelqu'un connait-il une solution autre que de payer pour la version payante de RideWithGPS? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Site-base-sur-OSM-qui-dessine-routes-ajoute-POI-exporte-en-GPX-ou-KML-tp5813488.html Sent from the France mailing list archive at Nabble.com. ___ 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
[Talk-us] Whole-US Garmin Map update - 2014-07-31
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2014-07-31 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2014-07-31/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2014-07-31 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
