Diary Comments added by Tomas Straupis
SimplifyVW (or DP) will remove too much important details (and no chance of exaggeration). It is not what human cartographer would do. For example human cartographer would never make meandering river into a straight line as that shows totally different attributes of the river to the geographer. Wang-Muller algorithm is offering a way to overcome that.
You can buy an excellent work of Swiss society of cartographers to get an idea of what pure wizards of cartography are doing (well if you do not have that already:-)
* demo document: https://kartografie.ch/wp-content/uploads/demo_no16_en.pdf
* old (free) version of the generalisation book: https://kartografie.ch/wp-content/uploads/nr02_generalization.pdf (but I suggest buying the new one as it is more aligned with the development of the technology, I can guarantee - for everybody interested in cartography it is worth each penny you pay)
(In my personal opinion this is the best resource I’ve ever came up on generalisation and I went through dozen of 1930-today period books from Europe, USA and Moscow, but please comment if you have an even better resource)
Opened information includes: address points, street centre lines with names (not precise geometry) and admin boundaries. Link to the data is correctly provided by MapMakinMeyers.
As for the number of points per address. One point per address is the way address information is created in the first place (by municipalities). If you want mapping of address to buildings - check OpenStreetMap data - when possible - we do move address tags onto the building. Note that addresses tagged with address:contact=yes are additional (duplicate) ones used for capturing address information for some POI.
No wiki. Data comes from geofabrik.de. Created with QGIS.
Having a list of errors also helps improving the homogeneity of the data.
Maps visualising types/positions of errors look cool, but they do not help the general process of QA. Idea is that wanted quality level must be reached and then maintained, therefore with each new automated error check introduced we:
This means that we mostly need a LIST, rather than a MAP.
Therefore we do have a LIST in our patrolling web-application, together with changeset approval and synchronisation with external datasets.
This also means that there are NO address errors which would live longer than one day.
(some too widespread, too hard to fix, or less important errors are on a different stream: some number of those ~10 are calculated and fixed daily, examples of such errors would be missing tracktypes, rivers with too sharp angles between segments, missing admin boundaries for “addr:city” etc. but those would once again be LISTS, not MAPS, and that is by design)
I do agree that the url is… well… strange, but that is a link I got in an official ICA (international cartography association) newsletter.
The link does work and it does return pdf without any additional/suspicious activities tho.
Thank you for interesting read! Indeed isolation/prominence is one of the other ways to calculate priority - which points are more important in order to remove the less important ones. And it should work very well for peaks (provided you do not have other classes competing for the same spot on the map). In case of water points all points without exception are important, therefore removing any points is not an option.
In Lithuania we use abbreviations for street, lake, wetland etc. names for the same reason - that is the official name. Makes it simpler to do different automated functionality. Shorter names is also cool but is not a deciding factor, as you can preprocess names for maps.
Copy relation ID and paste it in JOSMs open object dialog?
Totally agree with Frederik. OSMF is a SUPPORTING organisation, it has NO CONTROL over OSM whatsoever (other than switching databse on/off).
OSMF has no say on where OpenStreetMap can or should go. People who want to lead OpenStreetMap will do so and it does not matter what is OSMF opinion on it. Similarly if OSMF says “let’s do this and not do that” - it has absolutely no influence on what members of OSM do or think.
Therefore the term “board” is misleading to say the least.
Some very basics of IT: we are not creating a database from scratch here. There are already billions of objects and most importantly millions of different products created. Therefore doing a change which has a huge impact on those millions of products requires a very good reason and a clear benefit as such change will require months and maybe years of working time of many people to update their products.
You can imagine going to one of users of OSM and saying:
- please change all you water code, we’re changing the scheme.
They would ask:
- why? what is a benefit of a new change? I will have to spend a lot of time to update.
What would your answer be? “tags look prettier to me”?
You can tag all same classes of objects with original OSM water schema, so no benefit here.
Names of tags is insignificant detail which is only important to geeks/coders - not important at all to final product (say high quality government geodatabases use codes like gc04 instead of human readable tags and then have comprehensive descriptions on what those tags mean). Therefore switching to new scheme provides NO advantage whatsoever.
In JOSM if I add reservoir from menu it adds landuse=reservoir. But there is another option which adds russian schema tags. JOSM gives mappers a choice. iD does not.
Water slide tagging is not in my interest field, I’m not discussing about it specifically. My point is that for every water feature you have a tag to use without resorting to breaking huge amount of existing products.
I’m objecting to adding pointless water= tags semi-automatically and I’m also against usage of duplicate russian water tagging scheme in general.
How is original OpenStreetMap water scheme “stale”? What are you unable to map with it?
JOSM has a menu for water features and you can access all of them in one place, so no problem here as well.
The problem currently is in governance (in my opinion). There should be:
a) restriction of change of prominent features (which would have prohibited change of original OSM water tagging scheme, it could prohibit in future changing say highway tagging, as there are a number of ideas how it could have been made better). This part could be easy.
b) decision such as this is purely IT stuff, it must be done by people with actual IT experience, not by coders/geeks. This part is very problematic to implement for a number of reasons.
As for slides those are really nothing natural so cannot have natural=water tags. I would tag them with landuse=basin. So you can see that everything you want can be tagged with one tag. There is no point of introducing a scheme with pointless tag natural=water which says nothing, because you then need a second tag.
Important point: water scheme works now, you can already tag all different types of waterbodies. So there are no problems with original water tagging scheme -> no point of changing it, deprecating, introducing new schemes etc. There are much more useful thing to do.
A mess with water tagging was discussed a number of times in a lot of different places during those unfortunate years of existence of russian water schema :-(
If a pool is mistagged with natural=water you have to change it to appropriate tag like landuse=basin, not add another tag. You can tag anything you want with original OpenStreetMap water scheme, natural=bay or natural=lagoon can be your friends. You do not have to push a new scheme which has NO advantage over existing scheme. You can tag exactly the same types of waterbodies with new russian schema as with the original one.
Anybody thinking of changing such a prominent schema should think how THEY will spend THEIR time updating thousands of usages in maps, analysis, tests, documentation and how THEY will communicate this change to all users of OSM. Thinking that a lot of OTHER people would have to spend their time because of some geek idea is just selfish, irresponsible and IT-wise illiterate.
We need a MapRoulete challenge to find all water=* tags and correct them to appropriate tags like landuse=reservoir, waterway=riverbnak, landuse=basin etc.
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details <- this is the unfortunate russian water tagging scheme proposal. Made by at that time newby with no IT expertise. Unfortunately it was not noticed and overturned in time and it is now still bringing chaos into OpenStreetMap water tagging. Nobody noticed this schema until iD decided to force using it.
Note: Zverik (proposer) agreed at the time of proposal that his water scheme will not deprecate original (and still more popular) OpenStreetMap water tagging scheme.
Don’t know about lagoons and bays. Never though of them as separate waterbodies.
Lake is a naturally formed waterbody - therefore natural=water.
You can try tagging list, but there have been multiple attempts do “deprecate” original OpenStreetMap water scheme in favour of russian water tagging scheme, but the later one simple does not have any advantages over the original scheme. And water is a very prominent object, used in 99% of maps, so changing it is unwise in IT sense - anybody with at least a minimal IT expertise (coders are not “IT experts”) would say that changing tagging of such a prominent feature is a bad thing.
In original OpenStreetMap water scheme types of waterbodies are defined in main tag. Lakes - natural=water, reservoirs - landuse=reservoir, rivers - waterway=riverbank, and then all smaller types like landuse=basin. No need for any additional tag. Adding pointless tags automatically by a script does not give any value.
Your decision is based on existing tags only (not on local knowledge or other sources), this means you already have all information you need? Why adding new tags then?
Introduction of russian water scheme (where everything blue is natural=water) was a very unfortunate and unwise one. It makes no IT sense at all. It brakes current usage and provides absolutely no benefit as it will barely be possible to somehow make tag everything with natural=water, even with iD editor pushing it on newbies so much.
This is from russian water tagging scheme.
Original OSM water tagging scheme does not require ANY water tags.
Therefore please do not offer people to break good existing data (not all countries want to use russian water tagging scheme).
When moving vertexes of a polygon you can get into situation when a ring of a polygon crosses itself and then it is "not simple". This is what ST_IsSimple detects in my case in inner procedure, where only one ring is being processed.
But there is also a ST_IsValid check done with ST_MakeValid executed where we have full multipolygon with possibly multiple rings.