[talk-ph] LearnOSM and ToT Module Sprint Brief Report
Dear everyone, An initial report on the module sprint we just finished today (May 30 - June 1, 2014) Overview == This is a joint initiative of OSM-Ph, OSM-Id, HOT and ESSC. The objective of this sprint is to develop a trainors training manual by consolidating existing materials and experiences from previous OSM training activities in the Philippines and Indonesia. We intend to run a test of the developed materials to local partners in the Ph on June 10-13. Emir and Adityo of OSM-Id joined us here in the Philippines. What we worked on Here's a brief run down of what was developed. Our notes are available in hackpad [0] and the documents in gDrive [1] Everything is still a work in progress but of course, open for community comments and improvements. - Drafted a writing style guide for LearnOSM [2] - Drafted a content structure for LearnOSM [3] - Improved and added several sections [4 5] - Tasking Manager - Geofabrik extract and HOT exports - Using GPS 62s and newer eTrex models - Proposed a new category for mobile/smartphone mapping applicatiosn [6] - Workflow to convert LearnOSM to a printable PDF [7] - Materials and guides for an OSM Facilitator [1] - Training needs assesment questionnaire - ToT Modules - Learning framework - Other things - Discussion on attribution for imagery and screenshots we used in the materials [8] Thanks to the following === In-person [9] Maning Sambale (ESSC) Dianne Bencito (ESSC) Emir Hartato (OSM-Id) Adityo Dwijananto (OSM-Id) Eugene Alvin Villar (OSM-Ph) Erwin Olario (OSM-Ph) Julius Bañgate (OSM-Ph, UPD) Joined remotely RK Aranas (OSM-Ph) Ervin Malicdem (OSM-Ph) Everyone is invited to look into what we initially did and propose improvements. Thanks! === [0] https://hackpad.com/ep/group/F91lMjsbKUF [1] https://drive.google.com/?tab=moauthuser=0#folders/0B0XgzIymOZpfamZ3eXA2MHJaUWc [2] https://hackpad.com/Proposed-Style-Guide-for-LearnOSM-1JJxS8NIQSX [3] https://hackpad.com/Content-structure-4SqM9KImfim [4] https://github.com/hotosm/learnosm/pull/196 [5] https://github.com/hotosm/learnosm/issues/140#issuecomment-44772291 [6] https://github.com/hotosm/learnosm/issues/197 [7] https://github.com/essc/markdowntopdf [8] https://github.com/hotosm/learnosm/issues/198 [9] https://docs.google.com/file/d/0B-2WZQ1DwK_xUjJvMURVYkVqTVE/edit -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Jaagpad definitie
Ik heb me al dikwijls afgevraagd of er daar inderdaad een pad loopt aan de andere kant van Zemst. Nog nooit geprobeerd er te wandelen. Nog niet zo heel lang geleden is er een reportage geweest op Radio 2 over de jaagpaden. Dat dit dienstwegen van nv De Scheepvaart zijn, waarop zij voetgangers en fietsers toelaten. Dat ze veel last hebben van boze fietsers die klagen over de voertuigen die er rijden omdat ze bv. schepen moeten bereiken. zie ook http://www.descheepvaart.be/Rubriek/Recreatie/Jaagpaden.aspx ik zal een van de dagen de naam er in Rumst en omstreken terug afhalen met vriendelijke groeten m 2014-05-30 14:07 GMT+02:00 Glenn Plas gl...@byte-consult.be: Eigenlijk wel, een boot jagen betekent hem vooruittrekken vanaf de paden langs de rivier of het kanaal. Hem vooruittrekken vanop het jaagpad met andere woorden. Interessant, was idd om boten te trekken. Tx om het op te frissen :) Maar jaagpad heeft dus wel een zekere definitie, al ken ik de exacte wetgeving eromtrent niet. Maar er zijn regels over wat al dan niet toegelaten is op jaagpaden. Het is dus zeker gaan straatnaam. Dus wat mij betreft haal je die name=Jaagpad er gewoon weer weg. Ik heb de andere kant eens getagged. https://www.openstreetmap.org/way/285211906 Glenn ___ 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] Street Name
On 01.06.14 08:56, malenki wrote: they should name it Edelweißweg But for OpenStreetMap the only thing relevant is how it is written on the sign there... ;) /al (and what if it's a Swiss Edelweissweg ;) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Less than two weeks until SOTM-EU
Hi Am 31.05.2014 10:02, schrieb Frederik Ramm: and we're still looking for a couple people to lend us a hand during the conference, details here: https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers In particular are we still in need of Speaker Supports. As a Speaker Supporter you're in the rooms during the breaks before the talks and welcome the speakers. You'll ask how they'd like to present, test if their notebook works with the recording/beamer setup, connect them to the wireless microphone system, ask for their agreement to be recorded and live-streamed and support them with whatever questions they have. Sometimes you'll have to talk to the audience so they fill all seats when the room gets full. We're also still looking out for people helping with Video-Recording. We decided to also record the Sunday-Workshops and have no helpers for that day yet. The other Slots are already filled but a second person in the room would be useful. During the talks we need one person in each room, live-mixing the Video. This is, selecting between different Video-Sources, choosing when to show Slides and when to show the Speaker, regulating the loudness of the different room microphones and adjusting the camera settings. You don't need any special skills for that (JOSM is more complex ^^) and there are always people around who can help you in case something goes wrong. You'll get an introduction before your first task. On *Friday 6th June starting at 20:00* we'll hold a QA Conference-Call for those of you who have Questions or are unsure if they can or should help us. See https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers#Q.26A_Conference-Call for details. The SOTM-EU will not happen without your help, so go to https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers and enter your Name if we can count on you. Regards, Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Street Name
On 06/01/2014 01:56 AM, malenki wrote: On 30.05.2014 16:27, Alan McConchie wrote: Leavenworth is a former logging town that has been turned into a mock Bavarian village as a tourist attraction. So I'm not surprised that they are adding Weg to their streets to seem more Germanic. http://en.wikipedia.org/wiki/Leavenworth,_Washington If they want to have the street and its name even more and real German, they should name it Edelweißweg since Edelweiß in German is written with ß¹, in composed German words no white spaces are used – and Germans are usually great nitpickers in criticizing such trivia. :) Thomas ¹ http://de.wikipedia.org/wiki/Edelweiß_(Gattung) However, if they did so, most English-speakers would probably pronounce it Eidelwebweg, since English lacks that character. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Chinese doodles / vandalism
Dennis Raylin Chen wrote: Hi all I write a message to him to remind him OpenStreetMap is not place for random drawing in Chinese. Waiting for his response Dennis Thanks for that. However, they've edited again (changeset 22576684), it's obviously just doodles, and I've reverted it (changeset 22683892). Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Data Working Group (DWG) and Imports
Two recent events seem to have gone beyond reasonable discourse. The Dutch address imports and the addition of 5 US Bike Routes (USBR.) Unfortunately, these are not isolated instances. The mailing lists discussions have spiraled down to include personal attacks. I've chosen to use the subject DWG and Imports because these two subjects seem to end up with heated discussions. The OSM community can do better. I'd like to propose the following: 1. Adopt a Code of Conduct. The wiki has a draft proposal [1] for a Code of Conduct. Let's dust this off, approve it, and live by it. (HOT has a Code of Conduct [2] we could consult for revision of the draft.) 2. Last year the DWG proposed clarifying the Import Guidelines. [3] Let's organize a group of volunteers (because that's all we have) to review and revise the import guidelines. The makeup of the group should include people from different countries as well as a representative from the DWG. Until these guidelines are revised, let's use the existing guidelines. 3. The DWG should regularly report back to the community with data indicating the type of problems they encounter. That data should be made available to the Import Guidelines committee that I'm proposing. As a community we should be making decision, when possible, with good data. I strongly encourage the DWG to update their OSMF Tasks to include data based decisions making. I'd like to hear back from other that would like to see some positive change and would be willing to help. [1] https://wiki.openstreetmap.org/wiki/Community_Code_of_Conduct_(Draft) [2] https://wiki.openstreetmap.org/wiki/File:HOT_Membership_Code--proposal_for_annual_meeting_2014.pdf [3] http://wiki.osmfoundation.org/w/images/9/99/DWG_Plan_2013.pdf Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Working Group (DWG) and Imports
These are excellent, constructive suggestions. Thank you so much, Clifford, for taking the time to make them. There's much work to be done, and I agree wholeheartedly that the OSM community can do better. I'll start another thread to discuss a community-wide CoC. On Jun 2, 2014 4:22 AM, Clifford Snow cliff...@snowandsnow.us wrote: Two recent events seem to have gone beyond reasonable discourse. The Dutch address imports and the addition of 5 US Bike Routes (USBR.) Unfortunately, these are not isolated instances. The mailing lists discussions have spiraled down to include personal attacks. I've chosen to use the subject DWG and Imports because these two subjects seem to end up with heated discussions. The OSM community can do better. I'd like to propose the following: 1. Adopt a Code of Conduct. The wiki has a draft proposal [1] for a Code of Conduct. Let's dust this off, approve it, and live by it. (HOT has a Code of Conduct [2] we could consult for revision of the draft.) 2. Last year the DWG proposed clarifying the Import Guidelines. [3] Let's organize a group of volunteers (because that's all we have) to review and revise the import guidelines. The makeup of the group should include people from different countries as well as a representative from the DWG. Until these guidelines are revised, let's use the existing guidelines. 3. The DWG should regularly report back to the community with data indicating the type of problems they encounter. That data should be made available to the Import Guidelines committee that I'm proposing. As a community we should be making decision, when possible, with good data. I strongly encourage the DWG to update their OSMF Tasks to include data based decisions making. I'd like to hear back from other that would like to see some positive change and would be willing to help. [1] https://wiki.openstreetmap.org/wiki/Community_Code_of_Conduct_(Draft) [2] https://wiki.openstreetmap.org/wiki/File:HOT_Membership_Code--proposal_for_annual_meeting_2014.pdf [3] http://wiki.osmfoundation.org/w/images/9/99/DWG_Plan_2013.pdf Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Code of Conduct (was 'Data Working Group (DWG) and Imports')
Simply starting a new thread here to discuss implementing a Code of Conduct in our community, as suggested by Clifford (and many others before him). I haven't got time at the moment to share my full thoughts, but I wanted to create a separate place to discuss this specific proposal. I'll chime in as soon as I'm able. All the best from Berlin, Kathleen On Jun 2, 2014 4:22 AM, Clifford Snow cliff...@snowandsnow.us wrote: Two recent events seem to have gone beyond reasonable discourse. The Dutch address imports and the addition of 5 US Bike Routes (USBR.) Unfortunately, these are not isolated instances. The mailing lists discussions have spiraled down to include personal attacks. I've chosen to use the subject DWG and Imports because these two subjects seem to end up with heated discussions. The OSM community can do better. I'd like to propose the following: 1. Adopt a Code of Conduct. The wiki has a draft proposal [1] for a Code of Conduct. Let's dust this off, approve it, and live by it. (HOT has a Code of Conduct [2] we could consult for revision of the draft.) 2. Last year the DWG proposed clarifying the Import Guidelines. [3] Let's organize a group of volunteers (because that's all we have) to review and revise the import guidelines. The makeup of the group should include people from different countries as well as a representative from the DWG. Until these guidelines are revised, let's use the existing guidelines. 3. The DWG should regularly report back to the community with data indicating the type of problems they encounter. That data should be made available to the Import Guidelines committee that I'm proposing. As a community we should be making decision, when possible, with good data. I strongly encourage the DWG to update their OSMF Tasks to include data based decisions making. I'd like to hear back from other that would like to see some positive change and would be willing to help. [1] https://wiki.openstreetmap.org/wiki/Community_Code_of_Conduct_(Draft) [2] https://wiki.openstreetmap.org/wiki/File:HOT_Membership_Code--proposal_for_annual_meeting_2014.pdf [3] http://wiki.osmfoundation.org/w/images/9/99/DWG_Plan_2013.pdf Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[talk-au] Highway=path
I've been mapping stuff on OSM for a while but I've recently started doing my own rendering for gps. From this I've gained a new insight into the highway=path tag so am posting here. Firstly my focus is on tracks and trails so that is where I'm coming from. The basics of what I have noticed is that a lot ways are tagged highway=path with no other information. I have found this to be a difficult problem when it comes to rendering. The highway=path tag is a little different to the other highway tags. Firstly it covers quite a broad range of features for walking, cycling, horse riding. Secondly it has no default surface type. For example roads default is paved unless otherwise specified, highway=track defaults to unpaved. Highway=path doesn't have a default. Before messing around with rendering I would tag as highway=path and not bother too much with the other assortment of tags. Partly this is because there are heaps of tags that can be used and there was no particular direction on their priority or importance of use. For rendering I really need a surface tag included to separate the paths into practical catagories. Having no surface tag results in such a large mix of data that it becomes impractial to define any further. However if the surface=paved,dirt.. whatever is used the usefulness of the data is massively increased. For rendering I (and other examples of rendering I have seen) use the highway=path, surface=paved,dirt..etc tag to split the data into paths that are paved and paths that are not paved. This results in a practical ability to split surfaced paths (butumen, cement, pavers etc) and trails (gravel, dirt etc). I'd like to see the difference between: walking trails, dirt trails, single track etc. and paved paths, bitumen paths, concrete paths etc. And I'm sure I'm not alone in this. So in summary: highway=path is a unique tag because it covers a broader range of features than most tags. highway=path has no surface default like most other way tags do. adding the surface=paved,dirt,..,.. etc adds a much need qualifier for pratical rendering. My request: Firstly that people tagging paths consider adding the surface tag as well. You probably already know the surface (as I always did even though I didn't realise the significance of adding the tag) and if you're interested in paths your likely one of those most interested in having it rendered in a practical way. Secondly I think this is worth adding to the Australian Tagging Guidelines wiki in some form. ie Please add the surface=paved,dirt,..,.. etc when tagging paths. Preferred minimum being paved or dirt. What do you think? All the best, David ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] Pedido de Reversão
Olá, Solicito a reversão de 2 changesets: http://www.openstreetmap.org/changeset/22456257 http://www.openstreetmap.org/changeset/22456204 Eu havia mapeado a ferrovia de Cruz das Almas até a cidade de São Félix utilizando imagens do Bing. O usuário ze bernardes acrescentou um trecho a partir de São Félix, segundo ele com fontes do IBGE. Os dados porém são de baixa qualidade. A ferrovia atravessa pelo meio da cidade de Cachoeira, passando por cima das casas, o que não é verdade. Alem disso as imagens de satélite são claras e é possível mapear a ferrovia utilizando-as, sem a necessidade de importação de dados. Não tenho muita experiência com reversão. Assim, se alguém puder executá-la, agradeço. wille ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Pedido de Reversão
Uma curiosidade pergunto para vocês que trabalharam nisso: que [tipo de] dados exatamente, do IBGE, puderam ser aproveitados nesse mix. Este e-mail não é uma espécie de queixa; eu não sei mesmo. Em 1 de junho de 2014 19:21, Tarcisio Oliveira tarci...@ymail.com escreveu: Eu fiz um mix, as imagens de alta qualidade ajudaram e deu para encontrar o caminho correto em Cachoeira. E juntei os nós em Cruz das Almas Em 01-06-2014 18:27, Wille escreveu: Olá, Solicito a reversão de 2 changesets: http://www.openstreetmap.org/changeset/22456257 http://www.openstreetmap.org/changeset/22456204 Eu havia mapeado a ferrovia de Cruz das Almas até a cidade de São Félix utilizando imagens do Bing. O usuário ze bernardes acrescentou um trecho a partir de São Félix, segundo ele com fontes do IBGE. Os dados porém são de baixa qualidade. A ferrovia atravessa pelo meio da cidade de Cachoeira, passando por cima das casas, o que não é verdade. Alem disso as imagens de satélite são claras e é possível mapear a ferrovia utilizando-as, sem a necessidade de importação de dados. Não tenho muita experiência com reversão. Assim, se alguém puder executá-la, agradeço. 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Pedido de Reversão
São os dados do IBGE que estão disponíveis em formato de camada tipo o
do Bing
IBGE Rural
http://{switch:a,b,c}.tiles.mapbox.com/v3/tmpsantos.i00mo1kj/{zoom}/{x}/{y}.png
IBGE Urbano
http://{switch:a,b,c}.tiles.mapbox.com/v3/tmpsantos.hgda0m6h/{zoom}/{x}/{y}.png
JOSMhttp://imageshack.com/a/img834/2858/rfe0.jpg
Com o iDhttp://imageshack.com/a/img856/5343/mmdc.jpg
No caso o pessoal colheu informação do IBGE Rural como mostra a imagem
https://www.dropbox.com/s/l0i1m2pzco98r56/Captura%20de%20tela%202014-06-01%2022.29.50.png
na região http://www.openstreetmap.org/#map=14/-12.6674/-39.2314
Em 01/06/2014 21:43, Alexandre Magno Brito de Medeiros escreveu:
Uma curiosidade pergunto para vocês que trabalharam nisso: que [tipo
de] dados exatamente, do IBGE, puderam ser aproveitados nesse mix.
Este e-mail não é uma espécie de queixa; eu não sei mesmo.
Em 1 de junho de 2014 19:21, Tarcisio Oliveira tarci...@ymail.com
mailto:tarci...@ymail.com escreveu:
Eu fiz um mix, as imagens de alta qualidade ajudaram e deu para
encontrar o caminho correto em Cachoeira. E juntei os nós em Cruz
das Almas
Em 01-06-2014 18:27, Wille escreveu:
Olá,
Solicito a reversão de 2 changesets:
http://www.openstreetmap.org/changeset/22456257
http://www.openstreetmap.org/changeset/22456204
Eu havia mapeado a ferrovia de Cruz das Almas até a cidade de
São Félix utilizando imagens do Bing. O usuário ze bernardes
acrescentou um trecho a partir de São Félix, segundo ele com
fontes do IBGE. Os dados porém são de baixa qualidade. A
ferrovia atravessa pelo meio da cidade de Cachoeira, passando
por cima das casas, o que não é verdade. Alem disso as imagens
de satélite são claras e é possível mapear a ferrovia
utilizando-as, sem a necessidade de importação de dados.
Não tenho muita experiência com reversão. Assim, se alguém
puder executá-la, agradeço.
wille
___
Talk-br mailing list
Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org mailto: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] Pedido de Reversão
Ah, conheço. No iD prestou? Tem screenshot aí? Tentei e não consegui
visualização utilizável. Refiro-me ao iD. Ficou escuro.
Alexandre Magno
Em 1 de junho de 2014 22:32, Tarcisio Oliveira tarci...@ymail.com
escreveu:
São os dados do IBGE que estão disponíveis em formato de camada tipo o do
Bing
IBGE Rural
http://{switch:a,b,c}.tiles.mapbox.com/v3/tmpsantos.i00mo1kj/{zoom}/{x}/{y}.png
http://tiles.mapbox.com/v3/tmpsantos.i00mo1kj/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
IBGE
Urbanohttp://{switch:a,b,c}.tiles.mapbox.com/v3/tmpsantos.hgda0m6h/{zoom}/{x}/{y}.png
http://tiles.mapbox.com/v3/tmpsantos.hgda0m6h/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
JOSM http://imageshack.com/a/img834/2858/rfe0.jpg
Com o iD http://imageshack.com/a/img856/5343/mmdc.jpg
No caso o pessoal colheu informação do IBGE Rural como mostra a imagem
https://www.dropbox.com/s/l0i1m2pzco98r56/Captura%20de%20tela%202014-06-01%2022.29.50.png
na região http://www.openstreetmap.org/#map=14/-12.6674/-39.2314
Em 01/06/2014 21:43, Alexandre Magno Brito de Medeiros escreveu:
Uma curiosidade pergunto para vocês que trabalharam nisso: que [tipo de]
dados exatamente, do IBGE, puderam ser aproveitados nesse mix. Este
e-mail não é uma espécie de queixa; eu não sei mesmo.
Em 1 de junho de 2014 19:21, Tarcisio Oliveira tarci...@ymail.com
escreveu:
Eu fiz um mix, as imagens de alta qualidade ajudaram e deu para encontrar
o caminho correto em Cachoeira. E juntei os nós em Cruz das Almas
Em 01-06-2014 18:27, Wille escreveu:
Olá,
Solicito a reversão de 2 changesets:
http://www.openstreetmap.org/changeset/22456257
http://www.openstreetmap.org/changeset/22456204
Eu havia mapeado a ferrovia de Cruz das Almas até a cidade de São Félix
utilizando imagens do Bing. O usuário ze bernardes acrescentou um trecho a
partir de São Félix, segundo ele com fontes do IBGE. Os dados porém são de
baixa qualidade. A ferrovia atravessa pelo meio da cidade de Cachoeira,
passando por cima das casas, o que não é verdade. Alem disso as imagens de
satélite são claras e é possível mapear a ferrovia utilizando-as, sem a
necessidade de importação de dados.
Não tenho muita experiência com reversão. Assim, se alguém puder
executá-la, agradeço.
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
___
Talk-br mailing
listTalk-br@openstreetmap.orghttps://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-de] Richtfunkstrecken
Chris66 wrote Tja, der User Bahnpirat hat sich bisher geweigert, seine Quelle anzugeben. Das sind ja die allerbesten Voraussetzungen, das Zeug endlich rauszuschmeissen. gruss walter ps: aber wie ich den Laden kenne, hilft Aussitzen immer :( - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0.2[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Falsches-Kartenmaterial-Google-statt-OSM-tp5807495p5807673.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
Re: [Talk-de] Tagging für Geocaches
Am 31.05.2014 20:27, tumsi schrieb: Bin ich auch und durchs Geocachen und den auf dem Garmin genutzten OSM-Karten zum Mappen gekommen. Bei mir war es andersrum: Ich hab mir das Garmin für OSM gekauft und dann nach weiteren sinnvollen Anwendungsmöglichkeiten gesucht ;). Ich schließe mich deiner Meinung an: Geocaches (auf welcher Plattform sie auch immer initial gelistet sind) haben ABSOLUT NICHTS in der OSM-Datenbank verloren! Vollste Zustimmung! Ich sehe dadurch keinerlei Mehrwert, im Gegenteil, die doppelte Datenhaltung wird nichts als Probleme verursachen. Ich würde als Cacher nie auf die Idee kommen, mir die Informationen über Caches aus OSM zu ziehen, zumal da noch wesentlich mehr dahinter steht als nur die Koords. (Ebensowenig würde ich mir Öffnungszeiten etc. aus OSM besorgen, aber das ist ein anderes Thema). Ich meine, diese Diskussion hatten wir schon einmal, mit ähnlichem Resultat. Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noch knapp zwei Wochen bis zur SOTM-EU
Hi Frederik hat es schon angesprochen, ich möchte es noch etwas ausführen: wir brauchen noch Helfer für die SOTM-EU damit das funktioniert: https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers Insbesondere beim Thema Speaker Support könnten wir noch ein paar Leute brauchen. Unter Speaker Support wäre es deine Rolle, die Speaker in den Pausen und vor ihren Talks zu begrüßen, ihre Präsentationen auf den Präsentationsrechner zu kopieren oder ihr eigenes Notebook an den Beamer an zu stöpseln. Ihr müsstet die Speaker mit den Drahtlosmikrofonen verkabeln und sie Fragen, ob sie einverstanden mit Aufnahme und Liveübertragung sind. Ihr könnt euch für einzelne Slots eintragen, wenn ihr eh im Raum sein wollt unm die Talks zu sehen. Auch brauchen wir noch Helfer für's Video-Recording. Wir haben vor auch die Workshops am Sonntag aufzunehmen und brauchen dafür noch jemanden, der dort das Live-Mischen des Videos übernimmt. In dieser Rolle müsst ihr zwischen den verfügbaren Videoquelle wählen: Die Slides anzeigen, den Speaker oder beides zusammen. Auch die Kameraeinstellungen (Zoom, Ausrichtung) liegen in eurer Hand. Keine Angst - JOSM ist komplizierter. Für Freitag und Samstag haben wir bereits Helfer; damit die aber auch mal aufs Klo gehen können schadet es nicht, noch eine zweite Person im Raum zu haben. Für Helfer die noch Fragen haben oder sich noch nicht sicher sind wird es am *Freitag, 6. Juni ab 20:00* eine QA-Telefonkonferenz geben. Weitere Details dazu findet ihr auf der Wiki-Seite: https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers#Q.26A_Conference-Call Die SOTM-EU lebt von ihren Freiwilligen und Helfern - und ihr bekommt auch ein Super-Spezial-Orga-Shirt*! Tragt euch bitte in die Wiki-Seite https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers ein, wenn wir auf euch zählen können! Lg, Peter *) so lange der Vorrat reicht ;) Am 31.05.2014 09:58, schrieb Frederik Ramm: Hallo, nur noch mal eine kurze - und, versprochen, auf dieser Liste meine letzte - Erinnerung, dass wir in knapp zwei Wochen hier in Karlsruhe die SOTM-EU-Konferenz haben. Donnerstag 12. Juni - Vorabend-Treffen, Details werden noch bekanntgegeben Freitag 13. Juni - ganzer Tag mit Vorträgen, später Grillabend Samstag 14. Juni - ganzer Tag mit Vorträgen Sonntag 15. Juni - Hack-Tag, Exkursion, Workshops Wir haben ein tolles Aufgebot an Rednern (siehe https://www.sotm-eu.org/en/program) und Vorträge zu so praktisch allem, was in OSM dieser Tage wichtig ist - Routing, Rendering, Geocoding, Editiertechniken, Qualitätskontrolle, Spiele, und so weiter. Und natürlich haben wir großzügige Pausen, in denen man mit anderen Mappern und Entwicklern aus ganz Europa (und darüber hinaus - hallo USA und Japan!) reden kann. Wir erwarten so zwischen 200 und 250 Teilnehmer(innen), und eine(r) davon kannst Du sein, wenn Du Dich jetzt auf https://www.sotm-eu.org/en/program anmeldest! (Und wenn Du angemeldet bist, kannst Du Dich hier eintragen https://wiki.openstreetmap.org/wiki/SOTM-EU_2014 - wir suchen auch noch ein paar Leute, die uns bei der Veranstaltung helfen https://wiki.openstreetmap.org/wiki/State_Of_The_Map_Europe_2014/Helpers.) Wir zeichnen die Vorträge auf Video auf und viellicht werden sie sogar live übertragen, aber natürlich schlägt nichts das Selbst-Dabeisein! Also, sehen wir uns in Karlsruhe? Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
am Donnerstag, 29. Mai 2014 um 13:59 schrieb Bernhard Weiskopf: Die zeitliche Zutrittsbeschränkung möchte ich in OSM erfassen, damit Navigationsgeräte nur zu den Öffnungszeiten hier durchleiten. Du kannst es gerne eintragen, aber bitte gehe nicht davon aus, das es auch nur ein Routingprogramm gibt, welches diese Angabe nutzt. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am Sonntag, den 01.06.2014, 22:27 +0200 schrieb Christian H. Bruhn: am Donnerstag, 29. Mai 2014 um 13:59 schrieb Bernhard Weiskopf: Die zeitliche Zutrittsbeschränkung möchte ich in OSM erfassen, damit Navigationsgeräte nur zu den Öffnungszeiten hier durchleiten. Du kannst es gerne eintragen, aber bitte gehe nicht davon aus, das es auch nur ein Routingprogramm gibt, welches diese Angabe nutzt. Das sollte beim Mappen auch nicht das Kriterium sein. Wenn man kein Ei mappt, kann es auch keine Henne geben - oder so ähnlich ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtfunkstrecken
Am 01.06.2014 11:57, schrieb Walter Nordmann: Tja, der User Bahnpirat hat sich bisher geweigert, seine Quelle anzugeben. :-( Und das obwohl Bahnpirat schon lange bei OSM ist und eigentlich den Laden kennt... Das sind ja die allerbesten Voraussetzungen, das Zeug endlich rauszuschmeissen. Ich finde dass Richtfunk-Links als Strahlen (Linien) in den Daten als NICHTS verloren haben. Wenn dann kann man von mir aus einen Sender eintragen und dort die Gegenstelle (wenn bekannt) angeben. Aber virtuelle Objekte sollten draußen bleiben. Sonst kommt noch jeder und zeichnet den Weg ein den sein Hund quer auf irgendeiner Wiese immer rennt und behauptet das sei ein Weg oder ähnliches. Bei Wikipedia würde man jetzt einen Schnellöschantrag stellen: * Quelle/Lizenz unklar * Import/Eintrag ohne Konsens * Nutzen nicht nachgewiesen (keinen Relevanz ;-) Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging für Geocaches
Am 31.05.2014 15:33, schrieb Droelfzehn (aka Michael): ich bin beides (:-D) und der Meinung Geocaches haben NICHTS in OSM zu suchen, weil: [...viele sinnvolle Argumente...] +1 BTW: die Diskussion gab es vor 2 Jahren oder so bereits schon mal. Damals war den Konsens eindeutig: Geocaches gehören nicht nach OSM. Grüße, MichaelK. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am 30. Mai 2014 11:23 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-) Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die eines oeffentlichen Raumes / Strasse. Normalerweise gibt es da eine Hausordnung die genau so was sagt (klar, wer wie ein potentieller Kunde aussieht wird natuerlich reingelassen, solange er sich nicht laestig verhaelt, ist ja im ureigensten Interesse, moeglichst viele Kunden anzuziehen). Einfach mal im Internet gesucht und das erste angeclickt: http://www.mira-einkaufszentrum.de/hausordnung.html So was aehnliches gilt praktisch in allen Einkaufszentren. Gruss, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtfunkstrecken
On 02.06.14 02:28, Michael Kugelmann wrote: Aber virtuelle Objekte sollten draußen bleiben. Sonst kommt noch jeder und zeichnet den Weg ein den sein Hund quer auf irgendeiner Wiese immer rennt und behauptet das sei ein Weg oder ähnliches. Also der Vergleich hinkt IMO, für mich hat das eher die Qualität von Gasleitungen oder so. Das sind Dinge, die da sind, die aber keinen Orientierungswert haben, sondern der Sinn wäre nur der, großräumig Netze damit zeichnen zu können. Und da sollte man sich halt mal die Frage stellen, ob man das braucht/will. /al ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Piazza Castello di Milano
Come gli utenti OSM di Milano sapranno, Piazza Castello è diventata un'area pedonale a tutti gli effetti: c'è il cartello che la segnala http://www.firenzeinbici.net/public/02/01/cartello_area_pedonale.jpg e ci sono delle vere e proprie transenne che bloccano l'accesso ai veicoli motorizzati, perfino i ciclisti per entrare devono (o dovrebbero) scendere dalla bicicletta. Un po' di tempo fa avevo eliminato http://www.openstreetmap.org/changeset/22356568 tutti i sensi di marcia di Piazza Castello perché un'area pedonale non ne ha e perché non ci sono cartelli che segnalano il senso di marcia. Due giorni fa l'utente niubii http://www.openstreetmap.org/user/niubii ha eseguito questa modifica http://www.openstreetmap.org/changeset/22635000 in cui non solo ha ripristinato i sensi di marcia ma addirittura ha segnato le vie come residenziali, in contrasto con il vero e proprio cartello di area pedonale. L'oggetto della modifica è AMAT-MI: Aligned OSM graph to AMAT data. Secondo voi qual'è la cosa più giusta da fare? Come mai l'AMAT ha dei dati sbagliati? http://www.openstreetmap.org/user/niubii ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
Ciao l'utente niubii sono io. Innanzitutto grazie per la segnalazione. Ho trovato le way marcate con highway=pedestrian e oneway=yes, ho pensato ad un errore. Se vuoi rimetto highway=pedestrian e oneway=null A meno che non ci sia qualche ragione per lasciare oneway=yes. Ciao /niubii/ Il 01 giugno 2014 17:45, Andrea De Gradi dega...@gmail.com ha scritto: Come gli utenti OSM di Milano sapranno, Piazza Castello è diventata un'area pedonale a tutti gli effetti: c'è il cartello che la segnala e ci sono delle vere e proprie transenne che bloccano l'accesso ai veicoli motorizzati, perfino i ciclisti per entrare devono (o dovrebbero) scendere dalla bicicletta. Un po' di tempo fa avevo eliminato tutti i sensi di marcia di Piazza Castello perché un'area pedonale non ne ha e perché non ci sono cartelli che segnalano il senso di marcia. Due giorni fa l'utente niubii ha eseguito questa modifica in cui non solo ha ripristinato i sensi di marcia ma addirittura ha segnato le vie come residenziali, in contrasto con il vero e proprio cartello di area pedonale. L'oggetto della modifica è AMAT-MI: Aligned OSM graph to AMAT data. Secondo voi qual'è la cosa più giusta da fare? Come mai l'AMAT ha dei dati sbagliati? ___ 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] Piazza Castello di Milano
Francesco Pelullo, scusami ho perso l'email con la tua risposta (che però ho letto https://lists.openstreetmap.org/pipermail/talk-it/2014-June/043426.html) quindi ti rispondo senza citarti. Le oneway=yes le avevo rimosse in questo gruppo di modifiche http://www.openstreetmap.org/changeset/22356568, comunque se ripristini highway=pedestrian e oneway=nul, per me sarebbe meglio, la mappatura così risulterebbe coerente con i cartelli stradali presenti. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
No problem, questa sera rientro a casa e sistemo io. Non so bene qual è il limite dell'area pedonale, quindi ti invito fin d'ora a segnalare eventuali errori. Per completezza: tra piazza Castello ed il monumento a Garibaldi c'è un'area marcata highway=pedestrian name=Expo Gate. Non ci sono ways che la attraversano, questo potrebbe provocare qualche problema al routing. Ci sono problemi se ripristino due ways per attraversare l'area pedestrian? Altro problema a Milano: esistono decine di strade marcate oneway=no. C'è una ragione oppure si tratta di errori/dimenticanze? Stavo pensando anche ad un'altra possibile soluzione per Piazza Castello. Per mantenere le informazioni sulle corsie di marcia, sensi unici etc si potrebbe anche seguire un approccio diverso: lasciare highway=tertiary|unclassified oneway=* access=no in modo da impedire il routing e mantenere la struttura delle ways nell'area. E' una proposta, che ne pensate? Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
La quetione del oneway=no non la conosco ma penso che sia uguale a mettere oneway=null. In quanto alla questione dei sensi di marcia, quella è a tutti gli effetti un'area pedonale, un luogo dove ufficialmente possono camminare solo i pedoni e dunque non ha sensi di marcia (a cosa servirebbero poi dei sensi di marcia se le auto e le moto non ci possono entrare?) Tra l'altro le way in quell'area non hanno una struttura fisica ma erano semplicemente disegnate per terra, attualmente i pedoni in quell'area possono camminare come meglio preferiscono, non sono limitati alle way attualmente tracciate, personalmente sono favorevole a creare addirittura un'unica area=yes con highway=pedestrian. Vediamo però gli altri utenti cosa dicono. Il giorno 01 giugno 2014 19:14, Francesco Pelullo f.pelu...@gmail.com ha scritto: No problem, questa sera rientro a casa e sistemo io. Non so bene qual è il limite dell'area pedonale, quindi ti invito fin d'ora a segnalare eventuali errori. Per completezza: tra piazza Castello ed il monumento a Garibaldi c'è un'area marcata highway=pedestrian name=Expo Gate. Non ci sono ways che la attraversano, questo potrebbe provocare qualche problema al routing. Ci sono problemi se ripristino due ways per attraversare l'area pedestrian? Altro problema a Milano: esistono decine di strade marcate oneway=no. C'è una ragione oppure si tratta di errori/dimenticanze? Stavo pensando anche ad un'altra possibile soluzione per Piazza Castello. Per mantenere le informazioni sulle corsie di marcia, sensi unici etc si potrebbe anche seguire un approccio diverso: lasciare highway=tertiary|unclassified oneway=* access=no in modo da impedire il routing e mantenere la struttura delle ways nell'area. E' una proposta, che ne pensate? Ciao /niubii/ ___ 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] Piazza Castello di Milano
Am 01/giu/2014 um 17:45 schrieb Andrea De Gradi dega...@gmail.com: Un po' di tempo fa avevo eliminato tutti i sensi di marcia di Piazza Castello perché un'area pedonale non ne ha e perché non ci sono cartelli che segnalano il senso di marcia. premetto che non conosco lo stato attuale di Piazza Castello, e concordo che in assenza di segnaletica non va messo oneway, però generalmente un senso unico può occorrere anche in aree pedonali, perché ci sono quasi sempre eccezioni (taxi, delivery, residenti, emergency, disabled, ecc.) talvolta anche ristretto a certe ore. ciao, Martin___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
Am 01/giu/2014 um 19:35 schrieb Andrea De Gradi dega...@gmail.com: La quetione del oneway=no non la conosco ma penso che sia uguale a mettere oneway=null. è simile, per un router è uguale, ma ad un mappatore da un po' più di certezza: vuol dire che qualcuno ha controllato la way, invece senza il tag potrebbe anche essere incompleto. Da buona prassi non mettiamo oneway=no, quindi quando lo incontro mi fa esitare un momento (spesso si tratta di mappatura un po' strana o da principiante ;-). Comunque talvolta potrebbe essere anche sensato (qui è davvero a doppio senso!), per esempio insieme a width=2 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
On dom 1 giu 2014 17:45:49 CEST, Andrea De Gradi dega...@gmail.com wrote: Come gli utenti OSM di Milano sapranno, Piazza Castello è diventata un'area pedonale a tutti gli effetti: c'è il cartello che la segnala http://www.firenzeinbici.net/public/02/01/cartello_area_pedonale.jpg e ci sono delle vere e proprie transenne che bloccano l'accesso ai veicoli motorizzati, perfino i ciclisti per entrare devono (o dovrebbero) scendere dalla bicicletta. Non so se c'è un divieto specifico, ma per il codice della strada si può andare in bici in un area pedonale senza scendere...almeno io sapevo così... Un po' di tempo fa avevo eliminato http://www.openstreetmap.org/changeset/22356568 tutti i sensi di marcia di Piazza Castello perché un'area pedonale non ne ha e perché non ci sono cartelli che segnalano il senso di marcia. Due giorni fa l'utente niubii http://www.openstreetmap.org/user/niubii ha eseguito questa modifica http://www.openstreetmap.org/changeset/22635000 in cui non solo ha ripristinato i sensi di marcia ma addirittura ha segnato le vie come residenziali, in contrasto con il vero e proprio cartello di area pedonale. L'oggetto della modifica è AMAT-MI: Aligned OSM graph to AMAT data. Secondo voi qual'è la cosa più giusta da fare? Come mai l'AMAT ha dei dati sbagliati? http://www.openstreetmap.org/user/niubii ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Piazza Castello di Milano
Per superare le transenne ed entrare nell'area devi passare da un marciapiede. Il 02/giu/2014 00:18 Fabri erfab...@gmail.com ha scritto: On dom 1 giu 2014 17:45:49 CEST, Andrea De Gradi dega...@gmail.com wrote: Come gli utenti OSM di Milano sapranno, Piazza Castello è diventata un'area pedonale a tutti gli effetti: c'è il cartello che la segnala http://www.firenzeinbici.net/public/02/01/cartello_area_pedonale.jpg e ci sono delle vere e proprie transenne che bloccano l'accesso ai veicoli motorizzati, perfino i ciclisti per entrare devono (o dovrebbero) scendere dalla bicicletta. Non so se c'è un divieto specifico, ma per il codice della strada si può andare in bici in un area pedonale senza scendere...almeno io sapevo così... Un po' di tempo fa avevo eliminato http://www.openstreetmap.org/changeset/22356568 tutti i sensi di marcia di Piazza Castello perché un'area pedonale non ne ha e perché non ci sono cartelli che segnalano il senso di marcia. Due giorni fa l'utente niubii http://www.openstreetmap.org/user/niubii ha eseguito questa modifica http://www.openstreetmap.org/changeset/22635000 in cui non solo ha ripristinato i sensi di marcia ma addirittura ha segnato le vie come residenziali, in contrasto con il vero e proprio cartello di area pedonale. L'oggetto della modifica è AMAT-MI: Aligned OSM graph to AMAT data. Secondo voi qual'è la cosa più giusta da fare? Come mai l'AMAT ha dei dati sbagliati? http://www.openstreetmap.org/user/niubii ___ 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-westmidlands] Warwickshire aerial
Brian,
cc: talk-gb-westmidlands
The error message JOSM is giving on Warwickshire Aerial imagery is:
Image couldn't be fetched:
http://maps.warwickshire.gov.uk:80/gs/wms?SERVICE=WMSFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=Aerial_Photography:Aerial_Photography_2013STYLES=SRS=EPSG:4326WIDTH=500HEIGHT=500BBOX=-1.5006714,52.0905209,-1.4927313,52.0953991
If you try to open this url in a web browser you get an error report which
I've attached (its a text file so just open it in notepad).
Grant's version at [1] must be doing something different. Perhaps it's
requesting the tiles in the OS GB Nationalgrid projection (EPSG:27700)
rather than EPSG:4326. I can get the 27700 projection working in QGIS but
this is not supported in JOSM.
Our options are:
1. Speak with WCC to see if they can fix it their end.
2. Use Grant's url (which converts it from a WMS layer to a TMS layer)
Regards,
Rob
[1]
http://draco.openstreetmap.org/warwickshire-aerial-2013/{zoom}/{x}/{y}.jpg
wms
Description: Binary data
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-ro] osmose
Salut, Am reușit să instalez osmose[1] și să fac import de date pentru România. Importul a durat 20 de minute și a fost nevoie de 800MB memorie și 10GB spațiu pe disc. Încă nu am rulat vreo analiză și îmi e neclar unde trebuie să apară rezultatele, mai sap. -- Alex [1] http://wiki.openstreetmap.org/wiki/Osmose ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-ro] osmose
Update: am rulat și analiza, durează foarte puțin prin comparație cu import-ul. Am dat un mail celor de la osmose.openstreetmap.fr și au zis că ne dau parolă să uploadăm acolo rezultatele analizelor. Pentru cine vrea să se joace, am făcut un script[2] care instalează cele necesare pe un Ubuntu 14.04, și rulează analiza. -- Alex [2] https://gist.github.com/mgax/85920ce9d964fa70d894 On 01 Jun 2014, at 18:36, Alex Morega a...@grep.ro wrote: Salut, Am reușit să instalez osmose[1] și să fac import de date pentru România. Importul a durat 20 de minute și a fost nevoie de 800MB memorie și 10GB spațiu pe disc. Încă nu am rulat vreo analiză și îmi e neclar unde trebuie să apară rezultatele, mai sap. -- Alex [1] http://wiki.openstreetmap.org/wiki/Osmose ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-cz] Geoinformatics FCE CTU 2014
Ahoj, mohl by být AV záznam pro ty co nemohou, ale rádi by se podívali ? Dne 30. května 2014 14:50 Martin Landa landa.mar...@gmail.com napsal(a): Zdravim, Dne 15. května 2014 14:57 Jachym Cepicky jachym.cepi...@gmail.com napsal(a): Pánové (a přítomné dámy, jsou-li nějaké), nechcete si letos udělat sekci STOM? to by bylo idealni, ze strany CUZK mam prislibeny 4 prezentace / 4 ucastniky - RÚIAN, základní informace, - Vytěžování dat z RÚIAN - VDP, VFR, služby INSPIRE, - Kontroly dat RÚIAN a jejich opravy, - Reklamace dat RÚIAN. Jako termin pro sekci mi zatim vychazi ctvrtecni odpoledne ci patecni dopoledne. Ze strany OSM prispevatelu, bylo by vzajemne prinosne tuto sekci naplnit i prispevky ze strany OSM. Posilejte mi prosim kratke abstrakty [1] (v _cestine_) co nejdrive, at vime na cem jsme a muzeme tuto sekci zaradit do programu... Predem diky a tesim se na videnou! Martin [1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014#Submission -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Geoinformatics FCE CTU 2014
Dne 30.5.2014 14:50, Martin Landa napsal(a): Zdravim, Dne 15. května 2014 14:57 Jachym Cepicky jachym.cepi...@gmail.com napsal(a): Pánové (a přítomné dámy, jsou-li nějaké), nechcete si letos udělat sekci STOM? to by bylo idealni, ze strany CUZK mam prislibeny 4 prezentace / 4 ucastniky - RÚIAN, základní informace, - Vytěžování dat z RÚIAN - VDP, VFR, služby INSPIRE, - Kontroly dat RÚIAN a jejich opravy, - Reklamace dat RÚIAN. Jako termin pro sekci mi zatim vychazi ctvrtecni odpoledne ci patecni dopoledne. Ze strany OSM prispevatelu, bylo by vzajemne prinosne tuto sekci naplnit i prispevky ze strany OSM. Posilejte mi prosim kratke abstrakty [1] (v _cestine_) co nejdrive, at vime na cem jsme a muzeme tuto sekci zaradit do programu... Taky zdravím. Abstrakt odeslán (OpenStreetMap a kvalita dat). Letos jsem na tom s dovolenou bídně, akcí až moc a nějak se mi jí nedostává, takže zúčastnit se mohu pouze čtvrtek večer a celý pátek. No a teď ještě tu prezentaci :-D Marián Predem diky a tesim se na videnou! Martin [1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014#Submission -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nominatim a české adresy
Dobrý večer, hranice městských částí jsou v RÚIAN (jinak jsou definovány statutem - v Praze je to ve vyhlášce 55/2000 Sb., konkrétně v příloze č. 1), takže každý úředník by měl vždy vědět, co a jak. Jeho povinností je využívat data ze základních registrů. A ještě k zápisu adres - aby to nebylo tak jednoduché, tak zápis adresy je definován také v ČSN 01 6910 – Úprava dokumentů zpracovaných textovými procesory. K revizi této normy došlo letos v dubnu 2014. Je zde nadefinován zápis i jiných než územních adres, tj. např. poštovních přihrádek, atd. Petr Souček -Original Message- From: jzvc [mailto:j...@tpfree.net] Sent: Wednesday, May 28, 2014 6:27 PM To: talk-cz@openstreetmap.org Subject: Re: [Talk-cz] Nominatim a české adresy Dne 27.5.2014 17:53, Matěj Cepl napsal(a): On 2014-05-26, 18:19 GMT, Petr Morávek [Xificurk] wrote: Osobně jsem se (zjevně mylně) domníval, že číslo městského obvodu do adresy nepatří. Dokonce i formulář pro ověření adresy [1] obsahuje jen políčko Obec, nikoliv Městský obvod, takže je potřeba zadat jen Praha bez čísla, v opačném případě sice vyhledávání zafunguje, ale objeví se upozornění: Z mé temné právnické minulosti (ale už je to fakt docela dávno) si mlhavě pamatuji, že zákon o hl. m. Praze (nebo zákon o obcích?) praví, že obec je v Praze městský obvod (tj. Praha 1-22? chtělo by to sehnat aktuální znění) a ne Praha jako celek. Takže pokud chtějí Obec tak je správná odpověď Praha 3, nikoli Praha. Praha jako celek je kraj (a taky nemá starostu ale primátora). Matěj Sem si nevsim ze by na vjezdech do praglu byly znacky PRAHA 10 ... Navic i pokud se pokusis zjistit, kudy ze vlastne vedou hranice mestskych casti, tak zjistis, ze to nevedi ani urednici (staci trochu zagooglit a najdes desitky pripadu kdy pri reseni ruznych veci kolem nemovitosti posilaj urednici lidi od certa k dablu). ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mistni nazvy z cuzk:km - place=locality?
Dobrý den, v KM je místní a pomístní názvosloví , jehož součástí nejsou základní sídelní jednotky (ZSJ). V některých případech se samozřejmě bude ZSJ jmenovat stejně jako pomístní jména pozemkových tratí ve standardizovaném znění , ale nemusí to být pravidlem. Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Thursday, May 29, 2014 9:26 AM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Mistni nazvy z cuzk:km - place=locality? Ahoj, jen se zeptám - to, co je v KM, je to totéž co ZSJ v RUIAN? (Základní sídelní jednotky)? Pak nějak nedává smysl to překreslovat. ZSJ mají polygony i definiční body. Polygony už není kam dát, u definičních bodů se dá dát to place=*. Jináč Nominatim na to docela dost intenzivně reaguje, někdy až moc a hlásí places v dost velkých vzdálenostech, kde už by člověk asi ten název nepoužil (v případě použití bodů). Mám na mysli reverzní geokodér. Dne Čt 29. května 2014 09:10:19, Dalibor Jelínek napsal(a): Ahoj, jojo, to jsem delal ja. ;-) Kdyz uz se to nejak jmenuje, tak at to mame v mape, ne? S tim jak je to nahusto to by asi mela byt starost pro renderer a ne pro toho, kdo to z KM prekresluje. V tomhle zvetseni, na ktere jsi poslal odkaz, by to asi vubec nemel vykreslovat. Asi je to jinde o dost ridsi. V kazdem pripade si myslim, ze je lepsi to v mape mit, nez to neprekreslit, kdyz uz se ta oblast mapuje. Zdravi, Dalibor From: Jan Dudík [mailto:jan.du...@gmail.com] Sent: Tuesday, May 27, 2014 9:13 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Mistni nazvy z cuzk:km - place=locality? Zjevně nejsi sám http://www.openstreetmap.org/#map=14/49.1242/14.3598 JAnD Dne 27. května 2014 20:42 Martin Švec - OSM o...@maatts.cz mailto:o...@maatts.cz napsal(a): Ahoj, při přidávání lesních cest jsem začal opisovat z CUZK:KM lokální označení neobydlených míst (polesí, pole...) poblíž Brna. Zaplevelil jsem tím mapu trochu víc než jsem původně čekal, tak se chci ujistit, že nedělám něco nežádoucího. Viz http://www.openstreetmap.org/#map=14/49.2423/16.4198 Názvy jsou nody s tagem place=locality, po vzoru hopeta kousek severněji u Lažánek. Je to ok? Popis na wiki vcelku sedí (http://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality), ale prý by těch tagů mělo spíš ubývat. Vhodnější označení jsem ale nenašel. Turistické mapy tyhle názvy běžně obsahují, ale nevím jak je zkousnou renderery OSM... Díky Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Procédure pour addr:housenumber
Même dans le cas 1 si on supprime le batiment (il a été démoli), le noeud disparait avec (le fait qu'un noeud soit déclaré membre d'une relation à laquelle il n'est pas attahée par un way membre ne l'empêchera pas d'être supprimé. Si le batiment est démoli a structure de l'habitat est touchée, les futurs occupants d'une futur immeuble ne sont pas nécessairement situés à la même adresse, la parcelle peut avoir été divisée ou regroupée avec une voisine pour former une nouvelle construction. Si on place le noeud en bordure de parcelle celle-ci n'est pas non plus absolue, elle peut aussi bouger alors que le batiment reste en place (élargissement d'une voirie, construction d'un arrêt d'autobus, acquisition d'une bande prise sur un jardin, voire démolition d'une cloture pas toujours reconstruite par la collectivité qui l'achète en l'état sans forcément permettre au propriétaire d'en reconstruire une autre, faut de place, et sans non plus nécessairement le désir du propriétaire de remetre une clôture rendant difficilement pratiquable la bande restante de terrain) Il n'y a pas de règle pour dire ce qui va être conservé si un batiment doit être supprimé ou modifié, c'est du cas par cas. Le deux approches sont donc totalement équivalentes au final. La notion d'adresse est liée à l'occupation effective du terrain et des batiments et celle-ci évolue au gré des reventes, aménagements, divisions (souvent suite à successions), fusions (souvent pour reconstruire autre chose. L'adresse fait partue plus de la géographie humaine et sociale que de la géographie physique des terrains et bâtiments. Elle n'est pas figée les deux goégraphies s'adaptent tant bien que mal l'une à l'autre. Au delà de ça il y a la notion de parcelle fiscale pour le calcul des impots fonciers Mais au final les parcelles et bâtiments sont des surfaces, alors que les adresses sont des points choisi dans ces surfaces ou à proximité immédiate en fonction des accès à l'extérieur de ces surfaces. Il est difficile de dire alors quelle est la représentation la plus pertinente, les deux peuvent cohabiter et souvent devront le faire. Et il n'est pas surprenant alors que selon la méthode adoptée on a des rendus un peu différents. Ne te fie pas non plus à l'apparence des icones sur un rendu donne, il y a d'autres rendus qui ne font pas la différence et addichent la même icone ou le même chiffre, que ce soit sur un noeud d'adresse (sur la facade ou pas du batiment ou dedans ou à prioximité ou sur la limtie de parcelle) ou sur le centroïde d'une surface (batiment ou propriété close). Même la position des laques de numéro quand elles sont imposées par les communes peut ne pas correspondre à l'accès principal utilisé ou la boite à lettre et le locataire peut ne pas y élire domicile pour son courrier ou peut ne la considérer que comme résidence secondaire. Les mairies aimeraient bien attacher les adresses aux surfaces physiques, les batiments ou clotures, Mais les occupants choisissent eux mêmes leurs lieux de résidence principale ou secondaire et la poste s'adapte à leur demande. D'où le conflit : - doit-on mettre des adresses cadastrales ou des adresses postales ? Même le fisc ne tranche pas la question tant qu'il peut trouver un contribuable et le faire payer. Et pour la plupart des démarches administratives ce sont des justificatifs postaux qui sont demandés (factures adressées à l'occupant) sans que jamais on n'ait à justifier de la propriété ou d'un bail (même le bailleur s'en tient à l'adresse postale de son locataire). En fin de compte c'est l'occupant qui décide de son adresse pour ses démarches, puis obtient des documents qui servent ensuite à justifier des droits et obligations liées à l'adresse déclarée. (En France on ne se déclare pas en mairie comme en Belgique ou en Suisse, on le fait pour les impôts ou les services sociaux et on peut avoir autant d'adresses postales qu'on veut et à peu près où on veut tant qu'on a y accès à la boite aux lettres ; si on le déclare une adresse c'est le plus souvent pour demander à bénéficier d'un droit : tant qu'on reçoit le courrier de vérification, et réponds aux demandes tout va bien : on recevra sa carte d'électeur; ses avis d'imposition, ses factures et relevés de comptes aux adresses qu'on a déclaré séparément aux diférents organismes publics ou privés). On n'a même pas obligation d'avoir une adresse postale chez soi (la boite postale existe et de plus en plus ce n'est plus le courrier mais le téléphone ou l'email qui servent d'adresse de contact et d'outil de vérification; on peut déclarer ses impôts en ligne, mais il est même envisagé d'avoir une adresse mail pour les services publics, indépendant de l'opérateur de télécommunications, à note charge alors de faire relayer ces courriers, et de plus en plus on a des relais de notifications par SMS ; dans e privé c'est déjà fait et le téléphone mobile et la messagerie électronique font partie des moyens obligatoires, et on vous fournit le terminal d'accès
Re: [OSM-talk-fr] Rendu Bano : on n'a pas droit au zéro ?
Bonjour, J'ai trouvé des cas qui ressemblent même erreur signalée mais est-ce la même erreur ? , car, comme dans la question initiale, il s'agit de petits villages - 31081 - Bourg-d'Oueil - ; par contre, il n'y a pas eu de rapprochement : car il n'y a pas de noms de voies saisis dans OSM ni dans le fichier FANTOIR Bravo pour le travail effectué sur bano, car c'est une aide excellente pour trouver les nom de rues manquant. lenny Le 30/05/2014 09:58, Christian Quest a écrit : Un petit bug dans le requête... Je vais aussi ajouter le nombre total, mais après le pont car repos jusque Lundi (en principe). Le 30 mai 2014 09:21, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Bonjour, Une petite questions sur le rendu Bano. Quand toutes les rues ont été rapprochées entre le cadastre et OSM, est-ce que le rendu affiche bien zéro ? Je commençais à avoir un doute, et en vérifiant sur Ringeldorf (67, j'ai pris un petit village), tout à l'air rapproché, mais le rendu reste à 1... (Sinon, j'aimais bien dans la version précédente, le xx/yy pour indiquer l'avancement. Ce serait possible d'avoir la même chose sur le nombre de rues ?) Merci pour l'outil, JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Procédure pour addr:housenumber
Bonjour, Le choix d'indiquer le numéro addr:housenumber sur le polygone du bâtiment ou avec un point en façade peut être une question de goût ou de circonstances, chacun a ses préférences, il n'y a pas de consensus la dessus, mais il ne faudrait pas faire ce choix pour des questions de rendu étant donné qu'il existe plusieurs types de rendu et que le rendu pourra évoluer par la suite. Effectivement avec JOSM, l'adresse ne sera pas supprimée dans le cas 1 si on supprime le bâtiment, je trouve que c'est un avantage mais ça ne devrais pas non plus être un critère de choix. Le choix doit être fait par rapport à la qualité des données. Moi je préfère avoir un point en façade (cas 1) car je trouve ça plus précis, cela indique de quel côté du bâtiment il faut chercher a accéder à cette adresse. Si tu choisis le point en façade, il faudrait faire attention à bien l'intégrer à chaque fois au polygone (ce n'est pas le cas pour celui là [1]) Il n'est par ailleurs pas nécessaire de renseigner les tags suivants: addr:postcode, addr:city, addr:country car ces valeurs peuvent être automatiquement déduites depuis les limites administratives [2], les ajouter sur chaque addr:housenumber serait redondant (donc risque d'incohérence) Même chose pour le tag addr:street, pour éviter d'avoir des informations redondantes, soit on utilise ce tag pour chaque élément addr:housenumber, soit on intègre les éléments addr:housenumber et les highway de la rue associée dans une relation associatedStreet, mais faire les deux à la fois est superflu. Là non plus il n'y a pas consensus entre utiliser un tag addr:street, et utiliser une relation associatedStreet, d'après Pieren la tendance internationale penche nettement vers le choix du tag addr:street pour chaque addr:housenumber, plus simple à manipuler qu'une relation, mais le choix est beaucoup plus partagé en France. Il faut tout de même éviter de laisser un addr:housenumber sans lien vers sa rue [3] Si tu choisis la relation associatedStreet, pas la peine de lui ajouter les tags addr:* [1] https://www.openstreetmap.org/node/1724890868 [2] https://www.openstreetmap.org/relation/107906 [3] https://www.openstreetmap.org/node/1688471835 Le 31 mai 2014 22:37, nono pingven...@free.fr a écrit : Bonjour J'ai une petite question concernant le tag addr:housenumber Ici, http://osm.org/go/eriwR7njU?m= il est obtenu avec JOSM, cas (1) En créant un point puis en sélectionnant : Attributs - Commentaire - Adresse - Numéro + les points facultatifs (rue, ville, code postal, etc..) + relation Ici, http://osm.org/go/eriwxWylN?m= il est obtenu avec JOSM, cas (2) En sélectionnant le polygone du bâtiment et en ajoutant ensuite l'attribut addr:housenumber avec le numéro qui va bien. Le résultat est différent dans JOSM (et très peu pour le rendu OSM). Dans le cas (1) une plaque de rue apparaît et le numéro est là où on met la plaque. Dans le cas (2) il n'y a pas de plaque et le numéro est au centre du bâtiment. Dans le cas (2), si on supprime le bâtiment, on supprime également le numéro. J'ai mis ici : 5 vidéos sur ma façon de procéder pour le cas (1). Voir les 5 premières videos (dans l'ordre : http://zenith.noel.free.fr/nonux/osm/videos/ Merci de me dire si je fais bien ou mal. Quelle est la meilleure méthode ? nono -- Chuck Norris rend les virus malades. ___ 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
[OSM-talk-fr] Mapcraft sur l'import du bâti au Calvados
Bonjour,
En soutien à nos amis geek des adresses, il y a encore un travail de titan
pour l'import des bâtiments dans OSM.
Ce travail permet notamment à aider au positionnement des tags pour les
contributeurs, mais à des dizaines d'autres cas d'usages (rattachement des
adresses par exemple).
Le travail est facile à faire depuis son fauteuil, mais nécessite beaucoup
de contrôles visuels, il vaut mieux débuter par des petits villages.
Je vous propose donc le MapCraft suivant sur l'import du bâti au Calvados
http://mapcraft.nanodesu.ru/pie/426#
Actuellement il y a moins 536 communes à faire et au moins 170 communes de
faites (j'ai sûrement raté des communes).
C'est plus accessible que les adresses et il n'y a pas de débats sur la
façon de faire ;)
Quelques personnes pour aider ?
*
Le processus en quelques mots :
* Choisir une commune et se l'attribuer :
http://mapcraft.nanodesu.ru/pie/426#
* Télécharger les données sur http://cadastre.openstreetmap.fr/ et les
ouvrir dans JOSM
* Télécharger les données osm de la commune (fichier - télécharger -
Rechercher un lieu)
* Vérifier que l'image satellite est correcte (via les traces gps voir les
liens utiles)
* Si ce n'est pas bon, changer le statut mapcraft, libérer la zone et
passer à une autre commune.
* Si c'est bon, simplifiez les chemins avec le paramètre suivant :
simplify-way.max-error0.08
* Vérifiez l'alignement de chaque petit pâté de maison (la sélection en
lasso est très utile, ne pas dépasser plus d'une dizaine de maison d'un
coup, les décalages sont variables)
* Lancez le validateur JOSM pour corriger les intersections de bâtiment
entre eux ou avec des voies
* Envoyez sur OSM.org (par 100 ou 500 modifications) et actualisez le
statut mapcraft pendant ce temps
Liens utiles :
* utiliser le calque QA des zones à mapper dans JOSM permet de savoir tout
de suite si le cadastre vectoriel est disponible : tms[20]:http://
{switch:a,b,c}.tile.openstreetmap.fr/qa/{zoom}/{x}/{y}.png
* le calque des traces GPS sur OSM.org pour voir si l'image est bien
positionnée tms[22]:https://gps-{switch:a,b,c}.
tile.openstreetmap.org/lines/{zoom}/{x}/{y}.
Pourquoi le Calvados ?
C'est Christian qui a lancé l'idée pour la NIght of the Living Maps
proposait d'orienter nos travaux sur :
2014 ? je propose le Calvados (14) ! On y trouve un mix rosé assez dense
et bleuté/vert (beaucoup de bâti pas importé).
Pour moi, c'est aussi une région avec peu de montagnes et beaucoup à
mapper, ce qui est plus dynamique quand on y travaille.
--
Jean-Baptiste Holcroft
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapcraft sur l'import du bâti au Calvados
A titre personnel, je trouve dommage de laisser le bâti tout nu.
Je rajouterais au processus ;
* Les 'building=yes que la disposition (lotissement, ...) et les
images aériennes permettent d'identifier en maison individuelle ou
immeubles - building=house ou building=apartment.
* identifier les emplacement particuliers : mairies, établissements
d'enseignements, églises/monuments.
** Pour les mairies, c'est souvent mentionné sur les planches
cadastrales, sinon, y'a les propositions d'intégrations d'Osmose.
** Pour les établissement d'enseignement, c'est parfois mentionné sur
la cadastre, y'a aussi les propositions d'intégrations d'Osmose, et
les cours d'écoles ou de collège se repèrent souvent bien sur Bing.
** Pour les églises, idem, plus la forme du bâtiment. De plus, les
points géodésiques décrits avec des mots comme clocher sont souvent
de bons indices.
Art.
Le 1 juin 2014 15:26, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit :
Bonjour,
En soutien à nos amis geek des adresses, il y a encore un travail de titan
pour l'import des bâtiments dans OSM.
Ce travail permet notamment à aider au positionnement des tags pour les
contributeurs, mais à des dizaines d'autres cas d'usages (rattachement des
adresses par exemple).
Le travail est facile à faire depuis son fauteuil, mais nécessite beaucoup
de contrôles visuels, il vaut mieux débuter par des petits villages.
Je vous propose donc le MapCraft suivant sur l'import du bâti au Calvados
http://mapcraft.nanodesu.ru/pie/426#
Actuellement il y a moins 536 communes à faire et au moins 170 communes de
faites (j'ai sûrement raté des communes).
C'est plus accessible que les adresses et il n'y a pas de débats sur la
façon de faire ;)
Quelques personnes pour aider ?
*
Le processus en quelques mots :
* Choisir une commune et se l'attribuer :
http://mapcraft.nanodesu.ru/pie/426#
* Télécharger les données sur http://cadastre.openstreetmap.fr/ et les
ouvrir dans JOSM
* Télécharger les données osm de la commune (fichier - télécharger -
Rechercher un lieu)
* Vérifier que l'image satellite est correcte (via les traces gps voir les
liens utiles)
* Si ce n'est pas bon, changer le statut mapcraft, libérer la zone et passer
à une autre commune.
* Si c'est bon, simplifiez les chemins avec le paramètre suivant :
simplify-way.max-error0.08
* Vérifiez l'alignement de chaque petit pâté de maison (la sélection en
lasso est très utile, ne pas dépasser plus d'une dizaine de maison d'un
coup, les décalages sont variables)
* Lancez le validateur JOSM pour corriger les intersections de bâtiment
entre eux ou avec des voies
* Envoyez sur OSM.org (par 100 ou 500 modifications) et actualisez le statut
mapcraft pendant ce temps
Liens utiles :
* utiliser le calque QA des zones à mapper dans JOSM permet de savoir tout
de suite si le cadastre vectoriel est disponible :
tms[20]:http://{switch:a,b,c}.tile.openstreetmap.fr/qa/{zoom}/{x}/{y}.png
* le calque des traces GPS sur OSM.org pour voir si l'image est bien
positionnée
tms[22]:https://gps-{switch:a,b,c}.tile.openstreetmap.org/lines/{zoom}/{x}/{y}.
Pourquoi le Calvados ?
C'est Christian qui a lancé l'idée pour la NIght of the Living Maps
proposait d'orienter nos travaux sur :
2014 ? je propose le Calvados (14) ! On y trouve un mix rosé assez dense et
bleuté/vert (beaucoup de bâti pas importé).
Pour moi, c'est aussi une région avec peu de montagnes et beaucoup à mapper,
ce qui est plus dynamique quand on y travaille.
--
Jean-Baptiste Holcroft
___
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: [OSM-talk-fr] Mapcraft sur l'import du bâti au Calvados
Tout à fait en phase avec toi, le bâti est déjà une tâche assez longue en
soit donc je ne voulais pas trop pousser, on pourrait par exemple rajouter
les plans d'eau, routes unclassified, ponts et tracks, puis les passages
piétons, tout dépend du temps de chacun ;)
--
Jean-Baptiste Holcroft
Le 1 juin 2014 18:45, Art Penteur art.pent...@gmail.com a écrit :
A titre personnel, je trouve dommage de laisser le bâti tout nu.
Je rajouterais au processus ;
* Les 'building=yes que la disposition (lotissement, ...) et les
images aériennes permettent d'identifier en maison individuelle ou
immeubles - building=house ou building=apartment.
* identifier les emplacement particuliers : mairies, établissements
d'enseignements, églises/monuments.
** Pour les mairies, c'est souvent mentionné sur les planches
cadastrales, sinon, y'a les propositions d'intégrations d'Osmose.
** Pour les établissement d'enseignement, c'est parfois mentionné sur
la cadastre, y'a aussi les propositions d'intégrations d'Osmose, et
les cours d'écoles ou de collège se repèrent souvent bien sur Bing.
** Pour les églises, idem, plus la forme du bâtiment. De plus, les
points géodésiques décrits avec des mots comme clocher sont souvent
de bons indices.
Art.
Le 1 juin 2014 15:26, Jean-Baptiste Holcroft jb.holcr...@gmail.com a
écrit :
Bonjour,
En soutien à nos amis geek des adresses, il y a encore un travail de
titan
pour l'import des bâtiments dans OSM.
Ce travail permet notamment à aider au positionnement des tags pour les
contributeurs, mais à des dizaines d'autres cas d'usages (rattachement
des
adresses par exemple).
Le travail est facile à faire depuis son fauteuil, mais nécessite
beaucoup
de contrôles visuels, il vaut mieux débuter par des petits villages.
Je vous propose donc le MapCraft suivant sur l'import du bâti au Calvados
http://mapcraft.nanodesu.ru/pie/426#
Actuellement il y a moins 536 communes à faire et au moins 170 communes
de
faites (j'ai sûrement raté des communes).
C'est plus accessible que les adresses et il n'y a pas de débats sur la
façon de faire ;)
Quelques personnes pour aider ?
*
Le processus en quelques mots :
* Choisir une commune et se l'attribuer :
http://mapcraft.nanodesu.ru/pie/426#
* Télécharger les données sur http://cadastre.openstreetmap.fr/ et les
ouvrir dans JOSM
* Télécharger les données osm de la commune (fichier - télécharger -
Rechercher un lieu)
* Vérifier que l'image satellite est correcte (via les traces gps voir
les
liens utiles)
* Si ce n'est pas bon, changer le statut mapcraft, libérer la zone et
passer
à une autre commune.
* Si c'est bon, simplifiez les chemins avec le paramètre suivant :
simplify-way.max-error0.08
* Vérifiez l'alignement de chaque petit pâté de maison (la sélection en
lasso est très utile, ne pas dépasser plus d'une dizaine de maison d'un
coup, les décalages sont variables)
* Lancez le validateur JOSM pour corriger les intersections de bâtiment
entre eux ou avec des voies
* Envoyez sur OSM.org (par 100 ou 500 modifications) et actualisez le
statut
mapcraft pendant ce temps
Liens utiles :
* utiliser le calque QA des zones à mapper dans JOSM permet de savoir
tout
de suite si le cadastre vectoriel est disponible :
tms[20]:http://{switch:a,b,c}.
tile.openstreetmap.fr/qa/{zoom}/{x}/{y}.png
* le calque des traces GPS sur OSM.org pour voir si l'image est bien
positionnée
tms[22]:https://gps-{switch:a,b,c}.
tile.openstreetmap.org/lines/{zoom}/{x}/{y}.
Pourquoi le Calvados ?
C'est Christian qui a lancé l'idée pour la NIght of the Living Maps
proposait d'orienter nos travaux sur :
2014 ? je propose le Calvados (14) ! On y trouve un mix rosé assez
dense et
bleuté/vert (beaucoup de bâti pas importé).
Pour moi, c'est aussi une région avec peu de montagnes et beaucoup à
mapper,
ce qui est plus dynamique quand on y travaille.
--
Jean-Baptiste Holcroft
___
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-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bano − nouveaux rapprochements ?
Bonjour, Est-ce qu'un nouvelle série de rapprochement OSM-Cadastre va être lancée ? (C'est utile après une semaine d'ajouts de noms de rue de tous les cotés, on voit plus où on en est…). JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] cartesfrance.fr sans mention osm?
Bonsoir, J'étais tombé sur le site suivant il y a quelques temps... mais en y repassant ce soir, j'ai bien l'impression que les cartes téléchargeables grand format sont issues de données OSM? http://www.cartesfrance.fr/itineraire/ car il y a quelques défauts de rendu par chez moi qui me font penser très fortement que c'est une carte OSM... est-ce que vous avez la même impression? -- View this message in context: http://gis.19327.n5.nabble.com/cartesfrance-fr-sans-mention-osm-tp5807711.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] cartesfrance.fr sans mention osm?
La carte routière ressemble très fortement à OpenMapQuest... Et il n'y a pas le copyright OSM... Jean-Marc Gailis ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cartesfrance.fr sans mention osm?
Je pense de plus en plus que les partenaires commerciaux d'OSM qui proposent leurs services d'intégration de cartes en ligne ou dans les applications passent plus de temps maintenant à faire leur propre promotion et se contentent de mentions minimalistes du projet OSM en oubliant complètement de rappeler à leurs clients leurs obligations quant aux cartes déployées. Ils font preuve de négligence visiblement volontaire et si leurs clients créditent volontiers OpenMapQuest ou MapBox, oublient de plus en plus souvent les mentions obligatoires. Ces deux fournisseurs devraient fournir des modèles de conception les obligeant à rendre ces mentions obligatoires visibles par défaut. La customization peut être possible mais par une action volontaire de l'utilisateur qui confirme qu'ils ont bien lu leurs obligations et que leur application pourrait être testée et leurs droits d'accès à l'espace de service commercial retiré ou sévèrement limité à quelques utilisations permettant aux webdesigners de corriger et obtenir une nouvelle évaluation confirmant qu'ils respectent le droit. (Google le fait bien pour ses propres clients dans son API, Microsoft aussi, alors pourquoi pas MapBox ou OMQ ? A eux de fournir les outils pédagogiques et de support, ou de conception qui font les choses correctement, et le support nécessaire pour résoudre les cas compliqués d'intégration : après tout leurs clients payent ce service alors que nous on passe notre temps à les aider gratuitement même si c'est en leur rappelant leurs obligations, ou en cherchant pour eux des solutions selon leurs outils de conception web ou conception d'applis mobiles). La dessus, la Fondation OSM devrait insister davantage avec ses partenaires pour que ces collaborations ne soient pas à sens unique. Car pendant ce temps là ces partenaires commerciaux donnent très peu à la Fondation OSM en comparaison de l'immense travail fait par la communauté OSM sur les données (même si on intervient peu sur l'aspect technique des offres et plateformes des partenaires commerciaux, ce n'est pas notre rôle). Bref qu'ils fassent leur métier bon sang ! Surtout que leurs clients pourraient se plaindre auprès de ces fournisseurs en se demandant pourquoi on leur fait ces demandes puisque ces clients ne nous connaissent pas assez et pensent que le paiement des licences commerciales couvrent leurs droits et obligations. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cartesfrance.fr sans mention osm?
Bonsoir Pas sûr, chez moi les erreurs sont directement issues de Maps et sont corrigées depuis longtemps dans OSM Cordialement Le 01/06/2014 22:37, Jean-Marc Gailis a écrit : La carte routière ressemble très fortement à OpenMapQuest... Et il n'y a pas le copyright OSM... Jean-Marc Gailis ___ 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
[OSM-ja] 等々力渓谷Survey(東京都世田谷区）
三浦です。 今日は、等々力渓谷をSurveyしました。 https://www.openstreetmap.org/#map=18/35.60468/139.64412 歩いた中で、タグ付で悩んだものがありますので、 みなさんのご意見を伺いたいです。 それは古墳です。 http://ja.wikipedia.org/wiki/%E9%87%8E%E6%AF%9B%E5%A4%A7%E5%A1%9A%E5%8F%A4%E5%A2%B3 野毛大塚古墳という、帆立貝式の古墳だそうです。 周濠に囲まれ（水はないです）、壺が多数配置されています。 頂上は、円形に展望台になっており、こんもりした山になっています。 https://www.openstreetmap.org/#map=19/35.60499/139.64312 現在、入れては見たのですが、周濠の入れ方や、 壺のモニュメントの入れ方がこれで良いか、まったく自信がありません。 皆さんのコメントを伺いたいな、とおもいました みうら ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
On 2014-05-31 14:06, Serge Wroclawski wrote: Since there is no signage for these routes, this is an import and should be following the import guidelines. In the past, on-road bike routes were typically advertised via maps and annual guidebooks rather than reassurance markers. The U.S. Bike Route System is an official attempt to move beyond dead trees in favor of signage. State DOTs often post FUTURE shields years or even decades before an Interstate route becomes official. But no DOT has the budget to lavish that kind of attention on bicyclists. :-) The fact that these new routes currently have no signage certainly raises the bar for verification. Fortunately, primary sources like [1] are much less prone to data entry errors than actual databases. And unlike unofficial touring routes, there's nothing ephemeral about USBRs: any route change requires the written approval of an AASHTO special committee, as with an Interstate. If nothing else, authoritative sources can help to eliminate guesswork, which is one step towards ground truth. While we're waiting for signs to go up, the good news is that some states have opted to primarily route USBRs along existing off-road bike paths that we've already mapped through some combination of GPS tracks, local knowledge, and aerial tracing. The cycleways themselves can be verified on the ground. We just want to add the cycleway to an additional route relation. Detailed route logs would only be necessary for filling in the less obvious parts of the route. I've never gone through the formal import process -- for a lack of sources, not compliance -- but it seems to me that the guidelines are written as a defense against fly-by-night dumps of poorly vetted data. I'm sure anyone with raw bike route data would want to comply with the guidelines, but what about other kinds of sources? Many of the steps simply don't apply. So far, I've cobbled together a relation for USBR 50 in Ohio along well-known trails, based on descriptions in news reports and recorded village council meetings. Now that the route has been approved by AASHTO, it'd be very tempting to fill in the gaps based on the official route log. [2] Of course, I can't do that without ODOT's prior permission, in case of copyright concerns. But to give you a sense of how far removed this work is from a conventional import, I plan to use nothing more than iD or maybe Potlatch, adding lots of water towers and ballfields along the way. Steve is championing a piece of transportation infrastructure that could become a showcase for OSM's versatility but that currently needs a good deal of work. The USBRs are an opportunity for the OSM community to start productive relationships with DOTs and advocacy groups. We need more WikiProjects like it. [1] http://route.transportation.org/Documents/USRN%20Report%20May%2029%202014.docx [2] http://ballot.transportation.org/FileDownload.aspx?attachmentType=ItemID=1176 -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Fwd: USBRS WikiProject seeks volunteer mappers
Russ, My opinion is that this is a single data source issue. Unlike other data that we collect, there is nothing in the ground indicating the existence of this as a route. There's no sign indicating where the route is, so there's be no way to collect this data other than by looking at an external dataset and either importing or tracing. I think that's an import, because it's taking external data and applying it to OSM without even the potential for ground validation. I did mess up in that I needed to have stated, and will state now, that I was not talking from the position of the DWG. We have a lot of data that we could include in OSM that would be useful. Every so often someone wants to add property lines. I think those would be potentially interesting, but unsurveyable. These bike routes are similar. There's nothing on the ground that tells you that you're on the particular bus route- which means that the only definitive answer we could have about a bus route is some external dataset. If two OSMers disagree, the answer will always be What does the original data say? - rather than What does the ground look like? - right? I think that this kind of data doesn't belong in OSM. It's not something that lends itself well to OSM. It think it could be mixed in during rendering or for routing, but it doesn't belong in OSM proper. The issue of tracing vs importing is orthogonal to this question. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
On 6/1/2014 12:32 AM, Russ Nelson wrote: Why would that necessarily be imported? And how do you import a route, anyway? Similarly, there have been projects to add route relations to state and county routes. Depending on the availability of sources from the state, the mapper may end up working from PDFs of varying quality and making judgement calls in order to create those relations.Do we treat these projects as imports as well? ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 78, Issue 32
I am involved in similar work for the Bicitalia bicycle route network here in Italy. To be honest I had not considered even the possibility of considering this an import. The approach has been: Where already signposted the Bicitalia routes get inserted as normal relations. Where the routes were inserted in the final proposal phase, this happened in the following way: I checked manually in the map every single way both for geometry and tagging, and then inserted it into a relation with status=proposed. Checking for geometry is necessary because we have a couple of mappers in the area who put ways into the map, from areal photography, with TIGER1 precision, obviously not good enough for cycling. Sometimes ways would be missing altogether. We selected status=proposed for these reasons: 1) the route shows up as dashed on OpenCycleMap 2) as most, if not all ways of the routes, are already existent and can be used, it is useful for cyclists 3) a map with dashed lines is a very useful tool when talking to administrators, especially as you can see in this way how they are inserted into the cycling infrastructure (i.e. cycle paths and cycle lanes.) 4) the conversion to the final implementation of the route is easy In our experience point 3 has been particularly helpful. I think as this is a very manual and gradual process; I would not call it an import. Volker Padova, Italy On 1 June 2014 00:43, talk-us-requ...@openstreetmap.org wrote: Send Talk-us mailing list submissions to talk-us@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-us or, via email, send a message with subject or body 'help' to talk-us-requ...@openstreetmap.org You can reach the person managing the list at talk-us-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-us digest... Today's Topics: 1. USBRS WikiProject seeks volunteer mappers (stevea) 2. Re: USBRS WikiProject seeks volunteer mappers (Serge Wroclawski) 3. Re: USBRS WikiProject seeks volunteer mappers (Ian Dees) 4. Re: USBRS WikiProject seeks volunteer mappers (Serge Wroclawski) 5. Re: USBRS WikiProject seeks volunteer mappers (Frederik Ramm) 6. USBRS WikiProject seeks volunteer mappers (stevea) -- Message: 1 Date: Sat, 31 May 2014 12:17:10 -0700 From: stevea stevea...@softworkers.com To: talk-us@openstreetmap.org Subject: [Talk-us] USBRS WikiProject seeks volunteer mappers Message-ID: p06240801cfafd4d2c6ad@[192.168.31.124] Content-Type: text/plain; charset=us-ascii; Format=flowed OSM's USBRS WikiProject seeks volunteer mappers to help map new APPROVED United States Bicycle Routes. Please see http://wiki.openstreetmap.org/wiki/WikiProject_U.S._Bicycle_Route_System http://wiki.openstreetmap.org/wiki/WikiProject_U.S._Bicycle_Route_System , a reference and status report for the project. Effective immediately, USBR 1 in Massachusetts USBR 10 in Washington state USBR 36 and 37 in Illinois USBR 50 in the District of Columbia and USBR 50 in Ohio were declared by AASHTO as approved national routes. These are essentially equivalent to freshly opened Interstate highways, except these are for bicycles. Very helpful would be additional experienced OSM volunteers, comfortable editing OSM relations, to improve/complete USBRs 1, 10, 37 and 50 (in Ohio) by adding additional route members to a relation from a soft-copy map or text description of the route. If you wish to help build our national bicycle network in OSM, please contact me to obtain route data to enter into OSM. The wiki offers technical/tagging guidance, as well as acts as a progress reporting mechanism. It is important to communicate your intentions and progress via email or preferably wiki. The project has established process and enjoys new growth by asking widely for additional volunteers, so please pay attention to the many moving parts by keeping communication flowing where it needs to. (Get route data via email, wiki update your progress). USBRS is ~10,000 kilometers and has momentum to grow to 20,000 in the medium-term future. Help out by adopting a route near you! Though this work isn't difficult, each route might take a few hours of effort starting with an email. After you complete a route in OSM, one reward is to see the red line of a new, official USBR blossom in Cycle Map layer. Other rewards happen for on-the-ground participants (cities, counties, state DOTs, the public, stakeholders, bicycle coalition groups...), who see the route in our widely available map. This encourages more routes to emerge in a geographically friendly way, facilitating harmonious progress and further growth in our national bicycle network. To begin your contributions to this OSM WikiProject, reply using
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Maybe I should have cross-posted? Please see my recent post to the import-us list at https://lists.openstreetmap.org/pipermail/imports-us/2014-June/000583.html Oh, and thank you, Minh. While 'tis true that the USBRS itself (as physical infrastructure) needs a good deal of work, like a few more signs (it has some, but not a lot), it is also true that it is fairly well represented in OSM (as logical infrastructure, using the small cost of a few dozen route relations). AND it has been since July 2013! It's not easy, automatic pilot to keep it this way, but instead is a manageable and delightful bit of effort which I seem to have matched well with my passion to map. It is my pleasure to continue, should the community wish to support me doing so. A lot of people are trying to get along, make a large thing work, and we seem pretty close, except for a bit of ragged misunderstanding around some edges that are a bit smeary anyway. We can fix this. Heck, maybe we largely already have. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
I would love to see these routes in OSM, and I think it's a shame that there is such an ongoing fuss about it. I really do appreciate the on-the-ground verifiability rule, but given that even 'approved' imports like the NYC buildings most likely don't fully adhere to that rule, given that it's such a relatively small amount of data that would not even be visible on the osm.org tiles, and given the time and positive energy invested into this by Steve, I feel there is something else going on that ticks people off about this particular proposal. I would love to hear what that is, because I do want to understand why this is such a big ongoing issue. Martijn On Sun, Jun 1, 2014 at 6:19 AM, stevea stevea...@softworkers.com wrote: Maybe I should have cross-posted? Please see my recent post to the import-us list at https://lists.openstreetmap.org/pipermail/imports-us/2014-June/000583.html Oh, and thank you, Minh. While 'tis true that the USBRS itself (as physical infrastructure) needs a good deal of work, like a few more signs (it has some, but not a lot), it is also true that it is fairly well represented in OSM (as logical infrastructure, using the small cost of a few dozen route relations). AND it has been since July 2013! It's not easy, automatic pilot to keep it this way, but instead is a manageable and delightful bit of effort which I seem to have matched well with my passion to map. It is my pleasure to continue, should the community wish to support me doing so. A lot of people are trying to get along, make a large thing work, and we seem pretty close, except for a bit of ragged misunderstanding around some edges that are a bit smeary anyway. We can fix this. Heck, maybe we largely already have. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel President, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
My apologies for posting the last message using my openstreetmap.us account. This is my personal view, and has nothing to do with my official capacity as osm.us chapter board member. Martijn On Sun, Jun 1, 2014 at 10:33 AM, Martijn van Exel mart...@openstreetmap.us wrote: I would love to see these routes in OSM, and I think it's a shame that there is such an ongoing fuss about it. I really do appreciate the on-the-ground verifiability rule, but given that even 'approved' imports like the NYC buildings most likely don't fully adhere to that rule, given that it's such a relatively small amount of data that would not even be visible on the osm.org tiles, and given the time and positive energy invested into this by Steve, I feel there is something else going on that ticks people off about this particular proposal. I would love to hear what that is, because I do want to understand why this is such a big ongoing issue. Martijn On Sun, Jun 1, 2014 at 6:19 AM, stevea stevea...@softworkers.com wrote: Maybe I should have cross-posted? Please see my recent post to the import-us list at https://lists.openstreetmap.org/pipermail/imports-us/2014-June/000583.html Oh, and thank you, Minh. While 'tis true that the USBRS itself (as physical infrastructure) needs a good deal of work, like a few more signs (it has some, but not a lot), it is also true that it is fairly well represented in OSM (as logical infrastructure, using the small cost of a few dozen route relations). AND it has been since July 2013! It's not easy, automatic pilot to keep it this way, but instead is a manageable and delightful bit of effort which I seem to have matched well with my passion to map. It is my pleasure to continue, should the community wish to support me doing so. A lot of people are trying to get along, make a large thing work, and we seem pretty close, except for a bit of ragged misunderstanding around some edges that are a bit smeary anyway. We can fix this. Heck, maybe we largely already have. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel President, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Martijn van Exel wrote: I would love to see these routes in OSM, and I think it's a shame that there is such an ongoing fuss about it. May I gently offer some experience from n years of both mapping and developing National Cycle Network routes in the UK. (As well as being an OSMer I'm a regional group co-ordinator for Sustrans, the organisation that looks after and develops the NCN.) Generally in the UK we only map proposed NCN routes when a) we have some personal knowledge of them, and b) the route has a serious likelihood of being signposted in the next couple of years For example, I was happy to map NCN 442, our new route across the Cotswolds, as proposed because I knew very well that it was likely to open before long - not least because largely I identified the alignment and bid for the funding for it! And indeed it's now signposted and open: http://www.sustrans.org.uk/news/prime-minister-opens-new-section-national-cycle-network However, there are other proposed routes in the local area where there is no particular action underway at present to find funding or to fix issues identified with the route. For example, NCN 536 is a proposed route from Banbury (part of my patch) to Northampton, but: no funding has been identified, some physical works will be required before it can open, and the flow isn't currently deemed a priority. It's very unlikely indeed to open in the next two years, and consequently it isn't mapped on OSM. On occasion, mapping a proposed route can be actively dangerous and misleading. Sometimes a proposed NCN route will follow a busy road or rough terrain, or cross private land; fixing this will be one of the to-dos before the route can be opened. Showing it on a map, even as a dotted line, can encourage cyclists to venture into unsuitable conditions. (Yes, in theory caveat emptor, but I have encountered people who have been misled by such proposed routes showing on a map.) Obviously you'll make your own decisions, but I'd encourage you to follow similar principles for the USBRS project. Or in summary: OSM can be a little way ahead of reality... but not too far ahead. cheers Richard (making a rare break from my not-posting-on-mailing-lists rule) -- View this message in context: http://gis.19327.n5.nabble.com/USBRS-WikiProject-seeks-volunteer-mappers-tp5807660p5807703.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Thanks for sharing your perspective, Richard. Regarding OSM 'not being too far ahead' of reality - I think we should think of OSM as being part of defining that reality, rather than just following it. Authoritativeness in its traditional sense is an eroding concept, and with the quality of 'authoritative' data here in the U.S. being what it is, we see folks turning to OSM (and other citizen generated information sources) for information and answers. It has come to the point where governments are actively seeking out the help of OSM to keep their information current. This does perhaps not reflect the reality in most of Europe, where well-funded public and semi-public organizations for creating and maintaining geospatial information exist. But it is our reality, and probably that of large parts of the world. In that reality, I think OSM is instrumental in providing people with the best information they can get. With regards to trustworthiness (you allude to potentially dangerous situations resulting from mapping proposed routes) I would argue that OSM not only has the tools to alleviate those concerns, but also a maturing audience of users who realize that they are using a community-built information source. That is where I am coming from when I argue in favor of mapping these routes, and I hope it clarifies my position. Martijn On Sun, Jun 1, 2014 at 11:46 AM, Richard Fairhurst rich...@systemed.net wrote: Martijn van Exel wrote: I would love to see these routes in OSM, and I think it's a shame that there is such an ongoing fuss about it. May I gently offer some experience from n years of both mapping and developing National Cycle Network routes in the UK. (As well as being an OSMer I'm a regional group co-ordinator for Sustrans, the organisation that looks after and develops the NCN.) Generally in the UK we only map proposed NCN routes when a) we have some personal knowledge of them, and b) the route has a serious likelihood of being signposted in the next couple of years For example, I was happy to map NCN 442, our new route across the Cotswolds, as proposed because I knew very well that it was likely to open before long - not least because largely I identified the alignment and bid for the funding for it! And indeed it's now signposted and open: http://www.sustrans.org.uk/news/prime-minister-opens-new-section-national-cycle-network However, there are other proposed routes in the local area where there is no particular action underway at present to find funding or to fix issues identified with the route. For example, NCN 536 is a proposed route from Banbury (part of my patch) to Northampton, but: no funding has been identified, some physical works will be required before it can open, and the flow isn't currently deemed a priority. It's very unlikely indeed to open in the next two years, and consequently it isn't mapped on OSM. On occasion, mapping a proposed route can be actively dangerous and misleading. Sometimes a proposed NCN route will follow a busy road or rough terrain, or cross private land; fixing this will be one of the to-dos before the route can be opened. Showing it on a map, even as a dotted line, can encourage cyclists to venture into unsuitable conditions. (Yes, in theory caveat emptor, but I have encountered people who have been misled by such proposed routes showing on a map.) Obviously you'll make your own decisions, but I'd encourage you to follow similar principles for the USBRS project. Or in summary: OSM can be a little way ahead of reality... but not too far ahead. cheers Richard (making a rare break from my not-posting-on-mailing-lists rule) -- View this message in context: http://gis.19327.n5.nabble.com/USBRS-WikiProject-seeks-volunteer-mappers-tp5807660p5807703.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
On 2014-06-01 10:46, Richard Fairhurst wrote: Generally in the UK we only map proposed NCN routes when a) we have some personal knowledge of them, and b) the route has a serious likelihood of being signposted in the next couple of years This is pretty much the standard for mapping network=ncn routes in the U.S., now that the unofficial ACA routes have been demoted to network=rcn. However, there are other proposed routes in the local area where there is no particular action underway at present to find funding or to fix issues identified with the route. For example, NCN 536 is a proposed route from Banbury (part of my patch) to Northampton, but: no funding has been identified, some physical works will be required before it can open, and the flow isn't currently deemed a priority. It's very unlikely indeed to open in the next two years, and consequently it isn't mapped on OSM. Steve wasn't talking about proposed routes at all: USBRs 1, 10, 36, 37, and 50 are officially approved routes. There's nothing to open, though the signage situation varies from state to state. AASHTO designation doesn't come with a deadline for signage, but the state DOTs didn't go through the trouble of getting local and national approval just to sit on these designations. And when the signs do go up, we can be assured that they'll go up along the officially approved routes. On occasion, mapping a proposed route can be actively dangerous and misleading. Sometimes a proposed NCN route will follow a busy road or rough terrain, or cross private land; fixing this will be one of the to-dos before the route can be opened. Showing it on a map, even as a dotted line, can encourage cyclists to venture into unsuitable conditions. (Yes, in theory caveat emptor, but I have encountered people who have been misled by such proposed routes showing on a map.) The routes were approved along public roads in their current condition, so it isn't a matter of waiting for rights of way, bike trails, or lane reconfigurations. [1] In fact, most of the local jurisdictions in Ohio only supported USBR 50 because all they have to do is accept state-provided signage on their locally-maintained roads and trails. (They're all worried about cuts to state funding for local governments.) [1] In a few limited cases, the route log notes ongoing road construction along the intended route and provides a detour route. I think those cases should be handled just like standard construction detours. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Richard (Fairhurst): Thank you for most informative post, sharing with us in the USA your experiences of national bicycle network planning and especially mapping in OSM. Your gentleness is appreciated -- in fact, it goes a long way! The USA equivalent of the UK's Sustrans (as national bicycle route numbering authority) is AASHTO, a non-governmental organization which also holds authority to number the USA's Interstate Highway system (our national super-highways) as well as the century-old (or so) older US Routes highway system -- what might be called a national network of secondary highways next to the primary Interstates. Importantly, in the realm of AASHTO's Special Committee which designates Interstate, US Highways and USBR numbers, AASHTO assigns as proxy and/or partners with Adventure Cycling Association tasks of USBRS administration. In fact, you can see Kerry Irons' name here http://route.transportation.org/Pages/USBicycleRoutes.aspx on AASHTO's web site. Kerry (an august and respected poster here on talk-us for at least a couple of years) and I have been working together for over a year (and I even longer) to correct major mistakes in, and generally brighten up the USBRS so it now sings a vibrant harmony of what we (the USA) mean by our national bicycle route system. You can see the talk I gave on this topic April 13 at SOTM-US in Washington, DC here http://stateofthemap.us/session/us-bicycle-route-system-mapping . An absolutely VITAL understanding of how OSM must not get ahead of routing, proposals and reality was key to this process evolving as it did. Kerry and I were very sensitive to the problem of what was meant by proposed routes and our solution was to create a high bar standard before a route was even considered as a proposed route that might potentially enter OSM: there has to be a real statewide project (by a statewide Department of Transportation/DOT) before OSM might even consider making a route relation entry (for a proposed USBR). We recognized (firsthand with NE2's mess!) the dangers of proposed and we got on top of it with what we think is a very solid (and now well articulated) formalization. We have been documenting this (and implementing it) for the better part of a year. NOBODY in OSM suggests that we remove these routes -- in fact, quite the opposite -- I receive many hearty thanks and willing participants to improve the system via the adopt-a-route crowdsourcing methodology we have found to work quite well. After my talk, Serge and Paul (Norman) had lunch with me, and while they said that they did not represent the DWG, in fact they actually did. Serge characterized this as If a cop pulls you over and says 'I'm going to let you off with a warning', you don't then respond 'But I wasn't doing anything wrong' or more apropos, 'The law is unclear.' He challenged my assertion that a USBR is a real, tangible thing that ought to be mapped in OSM when it doesn't have signs: it can be verified (by a DOT or AASHTO or its proxy, ACA) but it cannot be verified ON THE GROUND if there are no signs. I did not disagree with Serge, but found this assertion to be both puzzling (there are MANY objects in OSM which are not on-the-ground verifiable, like borders, some county roads and even groups of state highway routes) and troubling (are USBRs in danger of being deleted?) No mention was made at that lunch about Import Guidelilnes or that the network's entry into OSM was an import. That came later. Because of contradictions in the support OSM has given to proposed from Day 1 (saying what it did on our wiki's Proposed page, since fuzzied and supposedly-clarified but unclearly possibly retracted by Fredrick's Red Triangle Warning) and the fact that mapnik/Standard and Cycle Map layer (OSM's #1 and #2 promoted renderers, respectively) clearly support proposed as dashed lines in numerous rendered outputs, my confusion rose to the level of a formal Plea for clarification to the DWG: specifically regarding how OSM should document APPROVED routes, and how OSM should document PROPOSED routes (if at all). As a reply, I was told it's in your best interest to let this discussion end and please drop this. I took that to mean that the nature of Proposed in OSM had rather suddenly changed (indeed, Frederick changed the Proposed wiki page hours later) and felt I had been stung with an ex post facto ruling. Still, I respectfully refrained from adding additional proposed routes because of this. However, a few days ago, AASHTO approved ACTUAL new USBRs (not proposed ones) and I felt OK asking the community to help map the several hundred kilometers of work it would take to sync up these new members in the system with our map. These are ACTUAL routes: on par with Interstate highways. They likely don't have signs today, but they shall/might in the future. And here we are. The similar principles that you
Re: [Talk-us] Fwd: USBRS WikiProject seeks volunteer mappers
Hi, Bike Route 1 on Cape Cod, MA is signed. I saw a bunch of them last summer biking around on vacation. In my opinion at this point the new routes should go through the import process, but given that signs are already up, and over time more are sure to come, I don't see any problem having the data in OSM. Jason On Sun, Jun 1, 2014 at 6:30 AM, Serge Wroclawski emac...@gmail.com wrote: Russ, My opinion is that this is a single data source issue. Unlike other data that we collect, there is nothing in the ground indicating the existence of this as a route. There's no sign indicating where the route is, so there's be no way to collect this data other than by looking at an external dataset and either importing or tracing. I think that's an import, because it's taking external data and applying it to OSM without even the potential for ground validation. I did mess up in that I needed to have stated, and will state now, that I was not talking from the position of the DWG. We have a lot of data that we could include in OSM that would be useful. Every so often someone wants to add property lines. I think those would be potentially interesting, but unsurveyable. These bike routes are similar. There's nothing on the ground that tells you that you're on the particular bus route- which means that the only definitive answer we could have about a bus route is some external dataset. If two OSMers disagree, the answer will always be What does the original data say? - rather than What does the ground look like? - right? I think that this kind of data doesn't belong in OSM. It's not something that lends itself well to OSM. It think it could be mixed in during rendering or for routing, but it doesn't belong in OSM proper. The issue of tracing vs importing is orthogonal to this question. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Steve, On Sun, Jun 1, 2014 at 8:34 PM, stevea stevea...@softworkers.com wrote: After my talk, Serge and Paul (Norman) had lunch with me, and while they said that they did not represent the DWG, in fact they actually did. Serge characterized this as If a cop pulls you over and says 'I'm going to let you off with a warning', you don't then respond 'But I wasn't doing anything wrong' or more apropos, 'The law is unclear.' He challenged my assertion that a USBR is a real, tangible thing that ought to be mapped in OSM when it doesn't have signs: Steve, there's so much wrong with your claim that I can't begin to take it all apart, but I will certainly defend myself against what I have no choice but to classify as plain ol' lies. What I said to you at that time was that I was not wearing my DWG hat in talking with you because the DWG hadn't received a complaint about the proposed routes, which were the issue we were discussing. These were not official routes, these were (and now I will quote you) [Using OSM as a] platform for discussion and debate in where the routes should be placed. I said that OSM was not a place for things which do not exist and are up for debate. That issue is quite clear and we had not one or two, at least three emails about it, in addition to the nearly hour long discussion we had at SOTM US. You then officially went to the DWG asking about the proposed and official routes, and the DWG position was that we were not going to intervene unless we received a complaint from a community member, but that if you kept pushing the issue, then the DWG would need to do an investigation, which might result in the deletion of your data. I didn't want to have to do that because while I think you were in the wrong, you were generally acting on what I felt to be good faith. I suggested to you that you drop the issue unless you wanted to make this official DWG business. In fact, you escalated the issue several times and I pleaded with you not to because I wanted to avoid needing the DWG to take an official stance on this data. That is where we left it. Proposals/plans do not belong in OSM. That is very clear. OSM is not a platform for debate about where things should be- it reflects ground truth only. USBR data is an edge case because it is not universally ground verifiable. The DWG has not taken a position on whether or not it belongs in OSM, but I personally believe that data which comes from a single source and is not ground verifiable does not belong in OSM. That view extends to government boundaries such as state and county boundaries. No mention was made at that lunch about Import Guidelilnes or that the network's entry into OSM was an import. That came later. That's correct, because you told me the work was done. If it was done, there was nothing left to discuss in regards to an import. Whether or not the non-proposed route data would be classified as an import is a matter of discussion. I personally believe that this would be an import- but am happy to entertain the idea that it's not- or whether or not the data belongs in OSM at all, which is still a discussion that needs to happen. The issue of utility, of course, is separate from the issue of Does it belong in OSM, as we have had the question of ground verifiability many times with data which would be useful to have, including property lines, bird spotting data, wifi access points, etc. Your email contains things which I believe you know to be false. That kind of behavior certainly does not make for a condusive collaborative environment and I believe that you owe both Paul Norman and myself a personal appology. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: USBRS WikiProject seeks volunteer mappers
Serge Wroclawski writes: My opinion is that this is a single data source issue. Unlike other data that we collect, there is nothing in the ground indicating the existence of this as a route. There's no sign indicating where the route is, so there's be no way to collect this data other than by looking at an external dataset and either importing or tracing. You're just a little bit insane, Serge. Let's say that I follow this route on my bicycle using a cue sheet and keep a GPS track. Then I load my GPS track into JOSM and create a relation and call it USBRS #47 (or whatever). How is this an import?? I think that's an import, because it's taking external data and applying it to OSM without even the potential for ground validation. You're twigging this as an import because there aren't any signs on the ground. What if I post my cue sheet on a sign? Again, how does this become an import? It bears none of the problems of imports: o imports create a whole new set of nodes. o imports can have copyright issues. o imports can be non-human-scale. o imports can be data dumps that don't get maintained. o imports make bulk changes to the database. This is nothing like that. Your *only* reason for calling this an import is because there aren't any signs. Yet. That reason isn't good enough to call it an import. We have a lot of data that we could include in OSM that would be useful. Everything that people care about having in a map is useful. You don't care about this. Fine. Somebody else doesn't care about something you want in OSM. Imagine *cooperating* with other people. I think that this kind of data doesn't belong in OSM. And when you see it on OpenCycleMap? Does it belong there? Should we fork the database now, so that we have a Serge OSM and a Nelson OSM and a USBRS OSM? Remember what I said earlier: a little bit insane. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
