Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tracking software changes #23
There is, of course, a lot of software that handles or uses OSM (multi)polygons. This includes, but it not limited to, editors and renderers. Generally all that we are doing here is backwards compatible, so changes in those programs are not strictly necessary, but the goal is to make handling (multi)polygons easier for the software, so we want to tell them about the work here and also get any feedback they might have.
This (meta-)issue is for tracking issues on software that should be aware of the fixing efforts.
Feel free to extend this issue with links to other projects that should be made aware of this effort.
This was referenced
Mar 17, 2017
referenced this issue
Mar 17, 2017
Regarding Potlatch 2 I don't think this is only a minor issue. The software still creates old-style multipolygons. After my clean-up in Austria I noticed two cases where old-style multipolygons were re-introduced in changesets by P2. E.g. https://www.openstreetmap.org/changeset/46925424 or more specifically https://www.openstreetmap.org/relation/7080945 which was cleaned up already by another user.
Given the position of the software in its life-cycle I think it is unlikely that big changes will happen to it. I don't think this will affect the data on a large scale, but I'm not familiar with the usage stats of P2.
I talked with Richard yesterday about P2. He is aware of the problem and might fix this. I suspect, though, he doesn't want to change the behaviour now to support both old and new style. It might make sense to wait a bit and then just support the new (and at that time basically only) style. This suspect this will only be solved really once the main OSM map switches to new-style-only.