[OSM-talk] Redacting 75, 000 street names contributed by user chdr
(sorry to break the thread; I was following the discussion through the archive, but I wasn't subscribed) Simon Poole wrote: > Our concern should be more about Mexico, Brazil and other countries > where it is at least not obvious to me if the local communities are > aware of the issue and if we have any plan at all how we possibly could > mitigate the impact. Most of the affected data in Brazil is located in São Paulo city, where we have data available from the city hall. In other areas we have data from IBGE. We can fill most (if not all) of the street names back again using licit data. We are aware of the affected areas and streets. And I guess that we can't say that all the data was copied from Google. In some places it differs from Google, while being too similar to Bing (unless that Google data from 6+ years ago was the same as the current Bing data). For example, https://www.openstreetmap.org/way/113013110 In OSM we have "Rua Rosa Marly de Souza" In Google we have "R. Rosa Marli de Souza" in IBGE we have "Rua Rosa Marli de Souza" In the official city map we have "Rua Rosa Marli de Souza" And, in Bing, we have "Rua Rosa Marly de Souza" See the word "Marly" (in OSM and Bing) and "Marli" (everywhere else) Another example https://www.openstreetmap.org/way/48514142 In OSM we have "Rua Professora Maria José Baroni F. da Silva" In Google we have ""R. Profa. Maria José Barone F. da Silva"" in IBGE we have "Rua Professora Maria José Barone F. da Silva" In the official city map we have "Rua Professora Maria José Barone Fernandes da Silva" And, in Bing, we have "Rua Prfa. Maria José Baroni F. da Silva" R. expands to Rua Profa. and Prfa. expands to Professora Take a look at "Baroni" (in OSM and Bing) vs "Barone" (in everywhere else) Another https://www.openstreetmap.org/way/131816621 In OSM we have "Rua das Margaridas" In Google we have "Rua Margarida" In IBGE we have "Rua Margarida" In the official city map we have "Rua Margarida" In Bing "Rua das Margaridas" "Rua das Margaridas" (OSM/Bing) vs "Rua Margarida" (other places) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM Custom Presets - Combo to set multiple tags
Hi Mike I don't think so since the combo box has a unique key name set in its definition What you can do though is to set the first key with a fixed value (religion=chrisitian) and let user pick for denomination Let us know how is it going François Le 29 août 2017 5:44 PM, "Mike Thompson" a écrit : I am learning how to create custom presets for JOSM. Is there a way to have a "combo" list set multiple tags? For example (just to illustrate the question), to make it so that if the user picks "Roman Catholic", religion=christian and denomination=roman_catholic are both set? Thanks, Mike ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geocoding guideline
Very good outcome ! I've made a quick french translation: https://annuel2.framapad.org/p/guidelines-geocodage-osm Edits are welcome, as it is 95% automatic translation from https://www.deepl.com/translator (very good new translator)... plus my own 5% quick edits ;) 2017-08-29 11:10 GMT+02:00 Simon Poole : > > I'm happy to announce that the geocoding guideline was endorsed by the > OSMF board at its last meeting and is now published on the OSMF website > https://wiki.osmfoundation.org/wiki/Licence/Community_ > Guidelines/Geocoding_-_Guideline > This hopefully addresses and clarifies a long time, sometimes hotly, > debated issue and will make it easier to use OSM data in more applications. > > Thanks to all that worked on the text and provided feedback negative and > positive. > > Simon > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] JOSM Custom Presets - Combo to set multiple tags
I am learning how to create custom presets for JOSM. Is there a way to have a "combo" list set multiple tags? For example (just to illustrate the question), to make it so that if the user picks "Roman Catholic", religion=christian and denomination=roman_catholic are both set? Thanks, Mike ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tuesday 29 August 2017, Jochen Topf wrote: > > When the old-style-mp support was disabled on the main map, this left > about 50,000 broken multipolygons, in many cases clearly visible on > the map. I didn't see a single complaint about this. So, no, I don't > think being a bit more strict with broken MPs will be a problem with > the map or would be a reason to delay deployment of a new osm2pgsql > version. 10,000 intersection problems in 300 million polygons is a > rounding error. I don't really want to repeat the discussion we had in https://github.com/openstreetmap/osm2pgsql/pull/684 My original idea stands: It would be good to have an idea how far the visual impact of dropping broken geometries has been reduced and if it has reduced a lot it would make sense to actually remove them in the standard map relatively fast before the numbers increase again. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tue, Aug 29, 2017 at 03:54:44PM +0200, Christoph Hormann wrote: > On Tuesday 29 August 2017, Jochen Topf wrote: > > > > > Would the number of visible problems in the map due to dropping > > > broken geometries now, after the fixing effort, be low enough so > > > this change could be made to the main map to give mappers a better > > > feedback about broken geometries? > > > > Osm2pgsql is switching to the libosmium MP code which is more strict > > than the older code before. As far as I know the code is finished and > > should be in the next osm2pgsql version. > > I am aware of that but this does not answer my question if the fixing > effort has significantly reduced the visual impact rolling out this > change to the OSMF servers would have. I would assume it has but the > OSMI does not really allow for a proper assessment here. When the old-style-mp support was disabled on the main map, this left about 50,000 broken multipolygons, in many cases clearly visible on the map. I didn't see a single complaint about this. So, no, I don't think being a bit more strict with broken MPs will be a problem with the map or would be a reason to delay deployment of a new osm2pgsql version. 10,000 intersection problems in 300 million polygons is a rounding error. Note also that Mapbox has been using libosmium code for a while and they are actively fixing large broken MPs every day to keep the map from breaking in a bad way. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tuesday 29 August 2017, Jochen Topf wrote: > > > Would the number of visible problems in the map due to dropping > > broken geometries now, after the fixing effort, be low enough so > > this change could be made to the main map to give mappers a better > > feedback about broken geometries? > > Osm2pgsql is switching to the libosmium MP code which is more strict > than the older code before. As far as I know the code is finished and > should be in the next osm2pgsql version. I am aware of that but this does not answer my question if the fixing effort has significantly reduced the visual impact rolling out this change to the OSMF servers would have. I would assume it has but the OSMI does not really allow for a proper assessment here. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tue, Aug 29, 2017 at 12:10:47PM +0200, Christoph Hormann wrote: > Date: Tue, 29 Aug 2017 12:10:47 +0200 > From: Christoph Hormann > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] Multipolygon fixing effort done > > On Tuesday 29 August 2017, Jochen Topf wrote: > > We have completed the 7-months effort to switch away from old-style > > multipolygons and fix a lot of broken (multi)polygons. More about > > this on my blog: > > > > https://blog.jochentopf.com/2017-08-28-polygon-fixing-effort-conclude > >d.html > > First of all congratulations to what was achieved, i.e. a fairly massive > reduction in the number of errors. > > The sad news however seems to be that given the current circumstances > the number of errors will likely be back to near the pre-cleanup levels > in 2-3 years for many types of errors. > > From my point of view this is because in contrast to the old style > multipolygons where > > * the problem was fully eliminated in the data > * the most important data user (the standard map) was changed to not > interpret old style MPs any more after that > * the major editors had already ceased to generate old style MPs long > ago > > the circumstances that lead to the large number of broken multipolygons > are essentially unchanged. We certainly got rid of a number of errors > from bad imports and can hope that future imports will be better in > that regard but the problem that mappers introduce this kind of error > in manual mapping and don't realize they are making an error is > unchanged. What has changed is that now without the complication of the old-style MPs it is easier to check for correctness of the data in editors and other tools. I hope that especially editor developers are looking at this problem more closely to identify common problems that can be fixed by better UI or better checking on their code. > Of the points above both completely eliminating MP geometry errors and > changing the editors not to upload broken geometries are things that > are very hard to accomplish. This leaves the third point and therefore > my question: > > Would the number of visible problems in the map due to dropping broken > geometries now, after the fixing effort, be low enough so this change > could be made to the main map to give mappers a better feedback about > broken geometries? Osm2pgsql is switching to the libosmium MP code which is more strict than the older code before. As far as I know the code is finished and should be in the next osm2pgsql version. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Beach routing
On Tue, 29 Aug 2017 13:36:49 +0200 Oleksiy Muzalyev wrote: > On 8/29/2017 12:50 PM, Jean-Marc Liotier wrote: > > ... > > I fail to imagine a beach that is not walkable. > > ... > > In France, yes. [..] In other parts there are still beaches which > could belong to a company, an organization, to a private person, and > there is no access there due to a fence or a barrier [..] Indeed I had forgotten that French littoral law is exceptionaly protective of the commons - by law one can walk along the entire French coast unhindered, except of course by physical features such as cliffs. But this is no different than highway modeling in Openstreetmap: by default the highway is accessible and access=* may specify exceptions to that - access=* can apply to natural=beach just as well as all the other Openstreetmap objects it already applies to. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Beach routing
This really needs routers to be able to route over areas, the same issue exists over large areas of grass such as found in parks or town squares. Phil (trigpoint) On 29 August 2017 12:00:48 BST, James wrote: >"Dont tag for the rendered" > >Routers should make beaches routable even though theres no clear path. >Same >with indoor mapping: I'm not going to add a bunch of paths in something >already tagged as a corridor/hallway > >On Aug 29, 2017 6:54 AM, "Jean-Marc Liotier" wrote: > >> Last week-end I went hiking along the coast from Honfleur to >> Trouville-sur-Mer. As I wondered what distance I walked, I turned to >> Openstreetmap routers... And did not find my answer: beaches are not >> considered as highways. >> >> I thought about adding paths to beach sections that I consider >> walkable... But, while some of those beaches have an identifiable >path >> along their length, for the most part this would be tagging for the >> router. >> >> I fail to imagine a beach that is not walkable. So, should the >routers >> use natural=beach the same way as >highway=path+surface=(sand|gravel|*) ? >> >> The question of routing across natural=beach brings back the past >debate >> about highway=pedestrian+area=yes - most routers do not route over >> areas. >> >> I just dug this thread, which goes along the same lines as my >reflexions >> >(https://lists.openstreetmap.org/pipermail/talk-us/2014-July/013280.html) >> but does no definitely concludes either. >> >> My conclusion is that I should open wishlist entries for my favorite >> routers... Is it a good idea ? >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Beach routing
On 8/29/2017 12:50 PM, Jean-Marc Liotier wrote: ... I fail to imagine a beach that is not walkable. ... In France, yes. And I understand by now why. I am currently reading Victor Hugo's "Les Misérables", and he writes in this novel that one of the reasons of the French Revolution of 1789 was that 96% people could not walk where they wanted, as the land belonged to the nobility (2%) and to the clergy (another 2%). In other parts there are still beaches which could belong to a company, an organization, to a private person, and there is no access there due to a fence or a barrier which is hardly visible form a satellite. And an access status can change with time, at one time there is a public access, then there is no access, then it changes again. But in any case, there are cities where seaside beaches are not walkable even inside city limits. Best regards, Oleksiy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Beach routing
"Dont tag for the rendered" Routers should make beaches routable even though theres no clear path. Same with indoor mapping: I'm not going to add a bunch of paths in something already tagged as a corridor/hallway On Aug 29, 2017 6:54 AM, "Jean-Marc Liotier" wrote: > Last week-end I went hiking along the coast from Honfleur to > Trouville-sur-Mer. As I wondered what distance I walked, I turned to > Openstreetmap routers... And did not find my answer: beaches are not > considered as highways. > > I thought about adding paths to beach sections that I consider > walkable... But, while some of those beaches have an identifiable path > along their length, for the most part this would be tagging for the > router. > > I fail to imagine a beach that is not walkable. So, should the routers > use natural=beach the same way as highway=path+surface=(sand|gravel|*) ? > > The question of routing across natural=beach brings back the past debate > about highway=pedestrian+area=yes - most routers do not route over > areas. > > I just dug this thread, which goes along the same lines as my reflexions > (https://lists.openstreetmap.org/pipermail/talk-us/2014-July/013280.html) > but does no definitely concludes either. > > My conclusion is that I should open wishlist entries for my favorite > routers... Is it a good idea ? > > ___ > 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] Beach routing
Last week-end I went hiking along the coast from Honfleur to Trouville-sur-Mer. As I wondered what distance I walked, I turned to Openstreetmap routers... And did not find my answer: beaches are not considered as highways. I thought about adding paths to beach sections that I consider walkable... But, while some of those beaches have an identifiable path along their length, for the most part this would be tagging for the router. I fail to imagine a beach that is not walkable. So, should the routers use natural=beach the same way as highway=path+surface=(sand|gravel|*) ? The question of routing across natural=beach brings back the past debate about highway=pedestrian+area=yes - most routers do not route over areas. I just dug this thread, which goes along the same lines as my reflexions (https://lists.openstreetmap.org/pipermail/talk-us/2014-July/013280.html) but does no definitely concludes either. My conclusion is that I should open wishlist entries for my favorite routers... Is it a good idea ? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygon fixing effort done
On Tuesday 29 August 2017, Jochen Topf wrote: > We have completed the 7-months effort to switch away from old-style > multipolygons and fix a lot of broken (multi)polygons. More about > this on my blog: > > https://blog.jochentopf.com/2017-08-28-polygon-fixing-effort-conclude >d.html First of all congratulations to what was achieved, i.e. a fairly massive reduction in the number of errors. The sad news however seems to be that given the current circumstances the number of errors will likely be back to near the pre-cleanup levels in 2-3 years for many types of errors. From my point of view this is because in contrast to the old style multipolygons where * the problem was fully eliminated in the data * the most important data user (the standard map) was changed to not interpret old style MPs any more after that * the major editors had already ceased to generate old style MPs long ago the circumstances that lead to the large number of broken multipolygons are essentially unchanged. We certainly got rid of a number of errors from bad imports and can hope that future imports will be better in that regard but the problem that mappers introduce this kind of error in manual mapping and don't realize they are making an error is unchanged. Of the points above both completely eliminating MP geometry errors and changing the editors not to upload broken geometries are things that are very hard to accomplish. This leaves the third point and therefore my question: Would the number of visible problems in the map due to dropping broken geometries now, after the fixing effort, be low enough so this change could be made to the main map to give mappers a better feedback about broken geometries? If the answer to this question is yes (or almost yes) we should not wait too long with making this step because once the number of errors has risen again this will again become increasingly problematic. And if this is not considered a practicable step there will of course be increasing need for libosmium to be able to fix these errors, at least the self intersections. ;-) -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD news: v2.4.0 released
Yes. A new contributor's first changeset count should be 1. On 26/08/2017 20:02, Bryan Housel wrote: Ok, I see what you mean.. Would it be ok if we just add +1 to the number before uploading the changeset? On Aug 26, 2017, at 2:17 PM, Dave F wrote: It does display the same number as is displayed on a user’s homepage, but that number is 0 before they have made any edits. It is a count of “how many edits has the user made before this one that they are saving right now”. As the contributor has just saved/uploaded the changeset, that sounds completely illogical to me. ___ 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] Multipolygon fixing effort done
We have completed the 7-months effort to switch away from old-style multipolygons and fix a lot of broken (multi)polygons. More about this on my blog: https://blog.jochentopf.com/2017-08-28-polygon-fixing-effort-concluded.html Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Geocoding guideline
I'm happy to announce that the geocoding guideline was endorsed by the OSMF board at its last meeting and is now published on the OSMF website https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline This hopefully addresses and clarifies a long time, sometimes hotly, debated issue and will make it easier to use OSM data in more applications. Thanks to all that worked on the text and provided feedback negative and positive. Simon signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
