Re: [OSM-talk] Ground truth for non-physical objects
I think, the problem that rule says "on-the-ground" and if it doesn't mean on-the-ground and people *cannot find it, * for example there is no sign at all like houses missing the number plate or abandonned houses or forest / national park divisions. Indeed, mail address is one of the possibility to check but they are not consistent. Sending 2 emails to correct-like address could give contradicting results easily because they are human processed. There is no need to discredit the rule, especially where it couldn't applied, there is a need to enhance the rule for a non-physical objects which are mostly driven by documents. And OSM was always fine to accept these imports driven by municipality documents. On Tue, 11 Dec 2018 at 12:28, Jochen Topf wrote: > On Tue, Dec 11, 2018 at 01:08:35PM +0200, Tomas Straupis wrote: > > I had an actual situation 5 or so years ago when an address was > > mapped in Vilnius. Address does not exist in official records. The > > user sent me a picture of this house number. I contacted municipality > > ant they explained that the sign is not an official one, it means > > nothing, there is no such address. > > It seems you haven't understood the on-the-ground rule 5 years ago and > you still haven't. For all intents and purposes there is such an > address. Mail will arrive there, people can find the house when looking > for it. It doesn't matter what the official record says. It doesn't > matter whether the address should be there or not according to some > authority. The address is there and it should be mapped that way. That > is what on-the-ground rule means. It works in practice. It works well. > And, yes, there are always corner cases. But that's no reason to > discredit the rule. > > 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 > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Feature Proposal - RFC - Mapping disputed boundaries
Hi All, It might sound a bit critical but I believe the ways *without a role * in admin_level=2 creates more confusion than bring value. First of all, the biggest value of admin_level=2: - to identify country as it is in UN - to have name translated in different languages - to have extra tags related to the country (probably spoken language or some details like right/left hand driving) - define further administrative structure *driven by local country authorities.* I like the idea that Ukraine has a proper admin subdivision for regions defined by local OSM community and it has Crimea registered with role "claimed" which is 1) indicative and 2) valuable Ways on these relations could be misinterpreted as 1) official boundaries by UN 2) boundaries that are controlled and patrolled by official army 3) boundaries "recognized" by OSMF 4) boundaries by constitution of the country itself . And it creates a mess of interpretation and doesn't help anybody. Another argument that ways of admin_level=2, these enormous relations are mostly broken and create issues for editing/validating anyway. In theory the users of admin_level boundaries could use the sum of further administrative division and subselect proper roles. So, I would suggest: 1) To get rid of non-role member ways from admin_level relation 2) But keep the ways themselves visible that will represent controlled boundaries Best Regards, Victor On Tue, 27 Nov 2018 at 09:33, Roland Olbricht wrote: > Hi all, > > a much simpler approach is to look into the respective constitution. > > The Ukrainian constitution defines the state's territory in article 133. > Other countries, like Germany do so as well, and Ireland does or has > done so. France does not define its terriotry in the constitution, and > the UK has AFAIK no constituation. Probably in both countires laws exist. > > Thus I suggest to create a relation comprising the regions mentioned in > that said article. It should hold the various name tags and a distinct > tag (not "boundary", "admin_level", or "source") to indicate that it is > a boundary according to the consitution, e.g. > "legitimation=constitution" (and "legitimation=national_law" if not > declared by the constitution). Countries where the constitution > conincides with the de-facto border can just get the tag. > > For Cyprus and Western Sahara, I have been unable to find the relevant > documents. I'm cautiously optimistic that they can be modeled in the > same way. > > Given that there is at most one constiution per country, that those are > designed to change infrequently and most countries are expected to > conincide, this allows to add no-nonsense data without opening a can of > worms. > > Best regards, > > Roland > > ___ > 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] Distribution of OSM ids could be much more useful!
Sorry messed up with interface, my reply was to Paul Norman but I didn't get his message so replied to a wrong email. I mentionned Permanent id because OSM anyway failed to implement it or didn't want to have it with sequential id. Best Regards, Victor On Sun, 25 Nov 2018 at 16:13, Tomas Straupis wrote: > Could you ealborate more on why you mention permanent id here? I see your > idea, but do not understand how it is connected to permanent id problem. > > There were some tests done regarding permanent id in Lithuania, but those > were regarding places of interest. > > If this has something in common, I could share some ideas and > observations, so that they do not now go in vain. Maybe somebody would like > to continue research, as this is quite an important thing to OSM. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Yes, I threw the idea slightly unprepared to create a discussion. May be it shouldn't be that revolutionary as using 30 bits for geo-location index but *16 bits *wouldn't change much. As I see, we are talking *density vs geo-index.* I understand, your point that most of (or some) software is built to optimize density but it should be able to take advantage from geo-index as well. > 33 bits of ids will mean 56-64-bit space for geo-index cache (wouldn't fit operating memory) As of today we are approaching 33 bits and we may never approach 36 bits. Though to build a geolocation cache we need to associate each id at least with its location i.e. int representing a tile. So we need to add to 33 bits - 30 or 32 bits and we end up around 64 bits, so it is almost impossible to keep a geo index in the memory. The operation of extraction is the most popular in OSM and there it could benefit the most i.e. iterating over Way nodes you can immediately say if it is valuable or not for your dataset which might fit the operating memory well. By the second run you can combine the ways you are interested with with the nodes. > Z-curve locality I don't see any problem with locality of Z-curve cause it would not be used in any algorithm I see. The algorithm would build Z-tiles index which are interested for data set extraction. >Density issue, how many bits is the best to store Of course, we could write an algorithm and find the best-ratio between id-distribution and bits allocated for geo-index. I would try to speculate with 16 bits. If we take only 16 bits, the most dense area I would see as Munich and its suburbs (8th tile zoom). As I see that tile takes around *60 MB in osm.pbf*. And it brings roughly 5 000 000 - 10 000 000 ids and it is *23 extra bits. *So we could safely assume that we will stay in *26 bits* and 16 + 26 = *42 bits *which falls under your assumption of dense software, I guess. The most important to say that difference between 42 and 34 bits is not huge for software at all cause there is always alignment by 8 bits. BTW: I could imagine that working with Whole planet is different use case where you need to maintain all global indexes and so on. Of course, by taking extra work on OSM DB and OSM API, it should help a lot 3rd party apps which don't process whole planet. Best Regards, Victor On 25 Nov 2018 06:36:39 -0800, Paul Norman wrote > It would be terrible for most software that I am aware of that can > process the full planet. Current assumptions about density would be > broken, vastly inflating memory usage and slowing down processing. > > The benefits aren't great as I see them. Using a z-order curve encoded > in the first 30 bits will help cache locality, but like all z-order > curves, it doesn't guarantee that two nearby places in 2d space have > nearby places on the curve. This means that an implementation still > needs to be able to search through the nodes for nearby ones. > > Two other problems come to mind. The first of these is implementation. > IDs are a PostgreSQL bigserial, and to write something custom that > assigns IDs based on location would be difficult as it would need to get > MVCC right. The second is the number of bits. Some software is limited > to 53-59 bits, and other to 63 bits. We're using about 75% of 33 bits > right now. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Distribution of OSM ids could be much more useful!
Hi All, As we know OSM id for nodes exceeded long time ago 2^32 and keep growing on the other hand the ids itself are pretty useless because they don't represent history good enough and also they couldn't implement principle of Permanent ID (https://wiki.openstreetmap.org/wiki/Permanent_ID). I suggest to discuss geometrical value of OSM id per node. Of course there is ongoing discussion to attach OSM nodes to ways, so the number of nodes will decrease dramatically but that's a long-mid term strategy. Much easier is to give some value to OSM ID. PROPOSAL. Dedicate 30 bits of OSM ids to the quadrant of the Globe (per square radiant) i.e. last *30 bits *of the ID could represent *15th zoom of globe radiant tile *(not Mercatoor projection tiles). What's useful. 1. Programs to import OSM could process it much faster cause id in the ways could indicate where physically the way is located. 2. Programs that store IDs could store much more compressed i.e. OsmAnd maps could benefit for storing maps in QuadTile structure and keep only part of id attached to QuadTile 3. It is a step forward to compress the data and have formats for faster processing and better storage. 4. Probably something more? Why it is easy to implement. - Doesn't require to change anything in the schema and in the tools - Most likely doesn't require to change any editor cause the changes could be postprocessed by the changeset commiter. - *Backward compatible!* Old ids before the given number could stay the same for a while. Challenges / Objections. - If you move a node from its original tile the history will be lost and id will be changed (I doubt it is a strong objection cause information could be partially / visually restored from changeset history). - The uploading changeset from editor could differ from result changeset stored in OSM API. What do you think? Best Regards, Victor ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSMF makes a political decision where should be a technical solution?
Hi All, I followed many topics for the last 3 days about the Ukraine/Crimea and I would like to propose another look to all known issues. *DISCLAIMER:* First of all, I would like to thank everybody for staying calm and considering all views for this *non-trivial* problem. Originally, I'm from Belarus (former USSR) and currently I live for a long time in the Netherlands, so I hope I can express my point of view objective but also explaining the gist of the issue. Even though I'm leading OsmAnd mobile development, I will speak solely from my perspective on this question. *STATEMENT 1. *There is no ToTG principle for artificial objects such as boundaries + Boundaries are always driven by one or another authorities. *1.1 *To clarify that principle we can go the lowest level, city or suburb boundaries. it is very clear that it is impossible to identify on the ground whether city-suburb has ended and another has started. *1.2 *Of course, we can clarify or build it that knowledge from milestone, flags or fence. Though we have different Mapping for fence, milestone and *we shouldn't mix it with country borders.* Following that principle, it will be hard to build polygons cause we always could miss data in between or it could be very incomplete from the Ground knowledge *1.3 *Most of the data today is coming from authorities. Local municipalities provide that public data, so admin_level of lower level corresponds to *1.4 *There is no ToTG to identify a country, unless you go and do a voting on the special piece of terriritory. I think you can find lots of places like Kurdistan where people would say that they belong to country that doesn't exist or not listed in UN. Country is an entity that coexist with other countries and other countries should acknowledge it and acknowledge their borders (especially for neighbor countries). *1.5 *Fence or any physically present object which could be verified by ToTG doesn't make border legitimate and will be very likely removed from admin_level relations doesn't matter if it looks or claimed by non-authorized entity a special territory if it contradicts to 99.9% perception of other mappers. With this point I'm trying to say, that hiding a solution behind ToTG principle we are raising even more questions than we had. *STATEMENT** 2. *There is no right decision unless we clarify what exactly data and how it should be organized. *2.1 *Moving objects or making special statements about concrete objects will drive to a mess. It is obvious that we better focus on Proposal and clarify how to deal with data rather than changing the map itself. *2.2 *Every mapper should be able to make the right decision himself following the wiki documentation. If it is not possible than the documentation or rules are not complete or not correct. We should not block people that do mistakes in understanding whether their logic correct or not especially if it is a significant number of people. *STATEMENT** 3. *Any decision about current Relations in OSM will be political and it will only evolve confrontation between local editing groups. I believe OSMF should not take any political decisions in such manner. I truly believe that DWG/ OSMF didn't want to make any political decision and only correct the data and make it consistent which makes perfect sense from top level view unless you don't bother with the real situation itself. Unfortunately it is not possible to solve political question and don't get dragged into politics. *3.1 *Hidden political decisions are bad. Why this decision is political? First of all, there is a small politics involved anyway DWG is elected by OSMF members and DWG made that decision. In case people are against it, they can vote for different DWG group and next year the situation around it will be changed again and again. The problem remains here anyway, what if Ukrainian community to vote will be smaller than Russian or what if votes can be based on various connections between people, so we'll get into a minority problem. *3.2 *THE WORST PART: We evolve confrontation between 2 big group of mappers which were always welcome in OSM but as of today they read OSM rules differently and the war of edits begins. In case we want to keep both group of mappers because they INDIVIDUALLY support different regions, we need to find a solution for both of parties. In that case I would actually support idea of deleting all country boundaries to avoid this question completely. *3.3 *DWG/OSMF should minimize any political impact with all possible technical solutions. I truly believe that this question could be solved with proper tagging mechanism and even more it could be solved on the level Google Maps solves it, by having different maps for locales UK_en. Everything should be considered and estimated in order to minimize reputation and diplomatic damage. *STATEMENT** 4. *Decisions should be focused on providing the most value to A) users/editors B) Applications -> to users in the
