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?
A) users/editors B) Applications -> to users in the end. *4.1 *openstreetmap.org website solves at most 5-10% use cases where OSM data There is not much critical that some features are not supported on it and it is first of all made to be useful for mappers where data through applications could reach much bigger audience and make mappers happier to impact on the world by small changes. *4.2 *Any decision about Ukraine osm-relation doesn't satisfy End-User application. For example, in OsmAnd we would like to display different maps for different regions and as of today we are forking country relations and doing lots of manual hard fork and all that is coming anyway from OSM but there is no way to contribute it back. We don't have clear algorithm to represent correct boundaries from Chinese Government perspective and in the end we don't represent any boundary correct at all which makes that data almost useless for End-User application. *4.3 *OSM should focus on providing as much and as relevant data as possible and solution will come naturally. If we focus to much what we can display on openstreetmap.org website we will bound ourselves of what feasible/not-feasible to implement on it where it is not necessary. Give right amount of data to the application and give an indicative algorithm for most typical use-cases and problems and it will be sufficient. For a sake of edit-wars some features could be disabled on the main website, so the data question will be leading. *4.4 *Making political risky decisions on the data side will transfer the legitimate problems to End-User applications which they wouldn't know how to solve correctly, basically it will have an amplifier effect. *STATEMENT 5. *Making a decision about Ukraine creates a very nasty precedent which should lead to other changes and raise another questions. *5.1 *Ukraine government doesn't control EAST part of Ukraine (even though there are some relations with citizens who live on that part). *So in that case Ukraine border should change again.* *5.2 *South Cyprus doesn't control North Cyprus https://www.openstreetmap.org/relation/307787#map=9/35.0525/33.8736. It also contain statement about UN recognition which could be applied to Ukraine and then Ukraine should contain Crimean and Russia shouldn't *5.3* Admin levels for China disputed territories are not consistent. Somehow Country level *contains less than all administrative child relations under it *(https://www.openstreetmap.org/relation/4052315 goes beyound country level) Other questions as well. So, it means DWG is not creating a rule but rather changing 1 local object which should be done by local community (in that case it should be ukranian community as Ukraine refers to it). *SOLUTION* I don't want to enumerate possible solutions cause I think if we spend enough time on it and invite people from different communities, we could find it easily. *P.S.* I hope we do not take that question as something that will die out in a week or in a month. Disputed territories were a painful part for OSM for a long time and the pain is only getting bigger. I totally support decision OSMF stay away from politics but it looks like if you don't get involve enough, then politics will start involving you in a different expected way. Thanks, Victor ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Follow up on last summer discussion about the Automated Edits Code of Conduct and the DWG
Hi, On 2017-04-21 08:18, Roland Olbricht wrote: > Thank you for keeping track of the issue. But I deem the summary > reflects neither the current situation nor the fidings of the discussion. You are right, it was a legacy of how this page started. But now, it's misleading and the intro isn't enough to clarify that. So I changed the name, the new URL is https://wiki.openstreetmap.org/wiki/User:Tuxayo/Automated_edits_code_of_conduct_and_DWG:_Follow_up_to_mailing_list_discussion_and_proposals Is that correct for you now? > Some key points: > > * There is no consent on what an automated edit is or not. Indeed, I thought it was not related to the topic but in fact it is. It seems a lot of disagreements are whether an edit is automated or not. > It is pretty clear that your example (changing all phone~"^http://"; to > "https://"; worldwide) is an automated edit. The grey cases are things > like the French buildings import, the MapRoulette challenge in the > Antartic region, and even the edit without local knowledge of Passau > main station (hence a pretty small changeset) of our company. > > All of these edits have at least made some data worse and have therefore > been discussed and partly fixed, partly kept for a reason. The fact that > the word "automated" did cause confusion gave rise to the > https://wiki.openstreetmap.org/wiki/Organized_Editing_Policy Thanks a lot I didn't know there was such a policy. > The two extreme positions are > - Any edit without local knowledge is by its nature flawed. > - We regulate only edits run by a bot. > > I personally (or we as a company) do not endorse any of the two extremes. > > They key point is that to be productive you should: > - define and publish your own criterion (e.g. one of > -- changesets of unusual large extent > -- unusual high activity per tag and day > -- changesets having "revert" in their comment) > - give it a specific name and set up a watch tool for it These are interesting ideas for monitoring tools. > * The DWG is not so special as you might think > > The DWG members are indeed special in dedicating huge amounts of time to > fix human misbehaviour, and we should be grateful for that. The DWGs job > is communication, not pushing around data. > > Most of the actual reverting is done by mappers outside the DWG. That's good to hear, how do you know that? I though a lot of people would report issues to the DWG instead of reverting themselves. Maybe it's only the case so automated edits? > Also, > DWG members do not have any special rights. Moderation (and possibly > redaction) is essentially done by the sysadmins, not the DWG. Aren't DWG members moderators? Which means they have the permission to block an account. https://wiki.openstreetmap.org/wiki/Web_front_end#Moderators https://wiki.openstreetmap.org/wiki/Data_working_group#User_Blocks > I agree that from outside, the DWG activity is hard to judge. The > problem here is that nobody has found a magic solution how to make DWG > activity public without asking the DWG for substantially more work, Would an issue tracking system suits this situation? > damaging the reputation of involved mappers, or both. Oh, good point. That indeed seems to make this impossible to solve without magic :( > I therefore would suggest to make clear-cut rules: > > a) If you can decide freely what to map, where to map, and how to map > then OSM will trust all your edits that are based on local survey. Happy > mapping! > > b) If you are directed by an organization (regardless whether you are > paid or voluntary) then use a dedicated account and put a line on your > user profile, e.g.: > http://www.openstreetmap.org/user/drolbr_mdv > That organization should have a corresponding Wiki page, e.g.: > http://wiki.openstreetmap.org/wiki/MENTZ_GmbH > > c) If you run a software where you do not approve as a human every > individual edit (every single change of a tag or change in geometry or > topology) then you need to follow the Automated Edits Code of Conduct > https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct That's great. It seems very clear and I don't see much ambiguity. > This still leaves open the case of Armchair Mapping of all shades. Indeed, this shows that Armchair Mapping is orthogonal to the 3 above categories. > An example with net benefit for OSM is MapRoulette. Therefore I would > suggest to ask Martijn first for his best practices and then start to > make rules on that. Ask about what exactly? About how to avoid the issues with armchair mapping? Cheers, -- Victor Grousset/tuxayo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Follow up on last summer discussion about the Automated Edits Code of Conduct and the DWG
Hi, Here you will find an approximate/subjective summary + some thoughts + some proposals : https://wiki.openstreetmap.org/wiki/User:Tuxayo/Automated_edits_code_of_conduct_and_DWG:_Mailing_list_discussion_summary_and_proposals Sorry for the delay, it took a lot of time to re-read the discussion, think about it and write this. Feel free to comment here or in the discussion section :) Cheers, -- Victor Grousset/tuxayo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Trails (paths) with no individual names
Should I use the name tag when mapping a system of connected trails that has a name, but where individual trail branches do not have names? For a specific example take a look at the Kildaire Farms Trail system I started mapping here: http://www.openstreetmap.org/?lat=35.75814&lon=-78.79265&zoom=16&layers=0B0FT I named the small branch going North from the trail junction with the same name as the main trail. There are other branches, some of which are quite short, that will probably clutter the map with "Kildaire Farms Trail" labels. I am thinking of keeping the name on the longest way and not naming the branches. What would you do? Thanks, Victor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Google Map Maker
Currently Map Maker is only enabled for a few areas that (I guess) don't have decent map data. Namely: # Bahamas # Barbados # Bermuda # British Virgin Islands # Cayman Islands # Cyprus # Grenada # Iceland # Jamaica # Netherlands Antilles # Pakistan # St. Kitts and Nevis # St. Lucia # St. Vincent and the Grenadines # Trinidad and Tobago # Vietnam On Tue, Jun 24, 2008 at 12:54 PM, X <[EMAIL PROTECTED]> wrote: > http://www.google.com/mapmaker/mapfiles/s/support.html > > Ready ... Fight ! > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] mapping a highway with multiple designations
Is there a way to deal with multiple highways using the same physical roadway. For example, this stretch of road here<http://www.openstreetmap.org/?lat=35.75518&lon=-78.67926&zoom=15&layers=B00FT>is used by I-40, I-440, US 70 and US 64. Can anyone advise on how this stretch of road supposed to be tagged? Victor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
