User talk:Cmuelle8

From OpenStreetMap Wiki
Jump to navigation Jump to search
See the archive for older discussion threads.

Future of areas

Hi, I saw you added info the the future of areas page. Thanks for structuring it.

Meanwhile, I also took the time to sum up some feature support per proposal in this table: User_talk:Sanderd17/Areas. If you agree with it, it could be added to the page too IMO. --Sanderd17 (talk) 15:39, 6 January 2016 (UTC)

The idea isn't bad, but imho more fields need a Yes/No (i.e. yellow) instead of a clear yes or no - this is why I originally tried to sum up the proposals using text descriptions only. Also, both of us should not be too anxious about a solution in the near future as there are lots of dependencies to think about when implementing any proposed change. What you could do as a first measure, is adding a link to this table in the section See also. If it's ok with you I'll write up concern over some fields later. Also, how/where in the article would you embed it so that readers do not give up on the complexity/length of the article? Do you intend to extend the current table or would you insert it at another point in the article? --Cmuelle8 (talk) 20:38, 6 January 2016 (UTC)
That's why I wanted to ask someone else (you in this case) if you find the table good enough, and worthy to include in the article, and how it would fit best (I'd just put it under your table). --Sanderd17 (talk) 10:15, 7 January 2016 (UTC)
Are you ok with me changing your table? I think it's the quickest way to show where I disagree. Also be aware that one header label is very suggestive, because it applies to one user group only: devs. I'm talking about the column number of area types - it may be true that more are harder to handle when writing software, but if you look at it from another perspective (i.e. mappers of varying expertise) more area types may mean more ways to express what's on ground. Also super areas e.g. are as hard to handle as the first variant of supermultipolygons, you need to write code to handle the simple and the recursive case, so this clearly is not comparable to the 1 you weighed other variants with. --Cmuelle8 (talk) 21:03, 6 January 2016 (UTC)
I'm certainly ok with you (or anyone) changing the table for the better. The "number of area types" also matters for mappers IMO. Less area types means less conflicts of people who thing one way of tagging is better suited than the other for that area (a bit like addr:street vs type=associatedStreet). You are right that recursive areas are harder to handle. But maybe that needs another column. --Sanderd17 (talk) 10:15, 7 January 2016 (UTC)

Proposal User:Sanderd17/Areas specific comments

discussion on january 7th

  • Let one area be made of three rings - we do not know if these are outer or inner rings, because the struct does not code it.
  • Let the first ways of each ring have an area left to it (for the purpose of this example; you could assign other sides at will, it will not change ambiguity), which is coded by the struct.
  • Then on a partial download of ways 1,2,3 you will color the dark gray area, sometimes it's correct, sometimes it is not - because all of the variants might complete that partial download.
However, if the struct does code the ring roles (and the rings are ordered) you should be able to color the correct side on partial downloaded data only. Note that you would need to employ your reverse tag in a manner that all ways of outer rings have the area to one side (after the reverse tag has been applied), preferably the left, and all ways of inner rings have the area to the other side, preferably the right.
You could code the ring roles by simply nesting ring definitions, it's easy in xml.
I've seen your revision of my summary of your proposal.
  • Can you explain what you mean by added? Fixed to a specific ring by the struct means that any way of your struct is associated with a specific ring (because you list the ways as children of specific ring parents) - fixed describes a property of your struct here. Compare this to multipolygons where ways are not fixed to a specific ring (which is expensive, because you have to compute which ring a way belongs to first).
Sorry, I just didn't understand "fixed" in that case. It sounded like the way was fixed to that ring only, and couldn't be used for other areas. Which clearly isn't the case. --Sanderd17 (talk) 10:15, 7 January 2016 (UTC)
  • The second thing you changed were my remarks about the need to compute outer, inner roles. You claim that areas are always left of a way, unless reversed attribute is set. However, this does not give you a clue of whether the complete ring will be an outer or an inner ring, because you cannot infer the orientation of the ring (clockwise or counter-clockwise) by this information. Refer to this picture:
There's no need to know whether the ring is an outer or inner ring. Topologically spoken, there's even no such thing as "outer" and "inner" on a sphere surface. What you need to know is which part of your bounding box is in the area, and which isn't (you're clearly not interested outside your bounding box either, else you would have downloaded that data).
You basically define if a node list is run one way or the other, but this does not give you the information which of these is a clockwise and which a counter-clockwise traversal. If you do not record which rings are inner/outer in your struct, you must rely on clockwise/counter-clockwise property of rings to decide inner/outer role by computation. To simplify this further: Without knowing the orientation of a closed way (being the simplest form of a closed ring), you do not know if the left side lies outside or inside. --Cmuelle8 (talk) 01:56, 7 January 2016 (UTC)
My proposal defines the orientation as the only way to determine where the area is. As a result, your bottom middle and top right example are probably not what the user means. F.e. in the top right, using the orientation would be equal to currently setting w1 as outer and w2 as inner. When rendering this, it means this will effectively colour the entire world. But, on the positive side, it's easy to both show the error to the users, and not mess up the entire world. A renderer that has information over all ways of the area object can limit its rendering to the bbox where ways of that area can be found. So when this orientation mistake is made, the bbox will show a negative rendering of the feature (so instead of rendering a pond, it will render everything outside the pond but inside the bbox as water). --Sanderd17 (talk) 10:15, 7 January 2016 (UTC)
<area id="..." ...>
  <tag k="..." v="..." />
  <ring> <!-- first outer ring -->
    <way ref="1" reversed="false" /> <!-- area is left -->
    <way ref="2" reversed="true"/> <!-- area left after reversed -->
    ...
    <ring> <!-- inner ring in first ring -->
      <way ref="5" reversed="true" /> <!--area right after reversed -->
      <way ref="6" reversed="false"/> <!--area is right -->
      ...
      <ring> <!-- outer ring in inner ring of first ring -->
        <way ref="8" reversed="true" /> <!--area left after reversed -->
        <way ref="9" reversed="true"/> <!--area left after reversed -->
        ...
      </ring>
    </ring>
  </ring>
  <ring> <!-- second outer ring -->
    <way ref="3" reversed="true" /> <!-- area is left of way after way is reversed-->
    <way ref="4" reversed="true"/> <!-- area is left of way after way is reversed -->
    ...
  </ring>
</area>
But explicitly coding inner/outer has not been part of your proposal, that's why you needed to compute orientation of each ring to find out, even with the full struct available (i.e. not partially downloaded). There are other reasons why it might be problematic to color partially downloaded areas: Retrieving data using a bbox looks at nodes, not ways, so if the other side of an area has a way segment without child nodes in the bbox, it won't be downloaded, even though that way intersets the bbox and therefore the area you download. In that case you can color the correct side for sure with sufficient info, but you will not know where to stop painting.. --Cmuelle8 (talk) 07:38, 7 January 2016 (UTC)
That way passing through a bbox without a node in it is already a problem with ways currently. It's not a problem specific to this area type, and all area types that allow partial downloading will have this problem as long as the way handling is the same.
Yes, this is true, it's not a problem specific to the area type you suggest, just jotting it for completeness. We have this issue now and it is not addressed by most proposals.
The rendering should stop at the bbox, so at worse, some corners of the bbox are rendered incorrectly. Mappers are also advised to not place points too far apart, even if it's a straight line, OSM has no definition whether straight lines are lines of constant bearing, or great-circle lines. So there should never be nodes in a way that are kilometers apart. Thus when you download something like a country extract with a small margin, you'll never run into this issue.
All in all, your ring nesting is interesting, but it raises questions on how to edit incomplete areas. I assume the editor would have to do this nesting automatically some way (as the user just needs to mark which side of the way is the actual area), but I do wonder if the editor can deduce the correct nesting based on partial data. When you have complete data, your outer-inner nesting is redundant information, so inconsistencies can cause correct rendering in one renderer, and incorrect rendering in another. Which could mask the issue and you could see f.e. that Mapnik renders it correctly, but your OsmAnd extract doesn't.
Editing incomplete areas is done like it is for multipolygons now - you can edit single rings, or even parts of single rings without having the complete data - this is, if the ring you are working is not reordered in the nesting tree, and the side the area is on for that ring part does not change. An editor can't compute nesting information of partial downloaded data, unless that nesting information is part of the area object and that nesting data of the area object is downloaded completely (you don't need way data).
You will not get inconsistencies, if the nesting is computed at times when this is possible (i.e. data is fully available) or only changed by valid operations on the nesting tree (e.g. you could think of inserting a ring somewhere in the hierachy, if the parent and all childs are fully downloaded at the point it is to be inserted).
See, this is the same with multipolygons currently: outer/inner may be redundant but invalid states of these objects stem not from the fact that this information is redundantly stored, but from the fact that you can enter and upload an invalid role membership - i.e. one that contradicts a correctly computed one. In that respect that information isn't even redundant, because redundant means it represents always the same result as the one given by computation. If editing software takes care of validating roles and/or the API checks validity at upload time, this is not a source of inconsistencies - it'd rather fix the cause why multipolygons are claimed to be fragile now.
I think that multipolygons are mostly fragile because they can't be rendered correctly when incomplete. And even when complete, JOSM will render the MP without caring about the outer or inner roles, and show a correct rendering even if the MP is invalid. So newbies don't know what they see in the case of incomplete MPs, or advanced users will not see the MP is "wrong" after editing. An extra problem with MPs is that they are just relations, and the OSM server has a history of allowing free tags (and doing no server-sides checks on those). So there can be no validation for MPs as the API only knows it's a relation. This validation issue can be improved for every dedicated area type. --Sanderd17 (talk) 20:11, 7 January 2016 (UTC)
Note that instead of the reverse flag, I could also use the terms left and right (i.e. the area is left or right of the way). This is probably the term an advanced editor would need to use, and let the user choose. For small areas, the reverse flag can be computed by the editor, instead of letting the user set it. --Sanderd17 (talk) 10:15, 7 January 2016 (UTC)
No, I think you're wrong here. I tried to make my point by the graphic above, but obviously its not clear enough. I scratched my head over a more minimal example to illustrate the problem with your approach and this is what I came up with. It is noteworthy that what you claim is correct, if your area type does not allow holes. In that case orientations of the rings do not need to be known in addition to if the area lies left/right to ways. But as soon as you want to represent an area object with an inner ring there are collisions decoding it (you cannot represent with your approach if the area consists of two outer or one outer and one inner ring (unless you additionally compute the orientation of the rings, like i said), see yourself):
Osm-defining-the-inside-of-an-area-by-coding-solely-if-it-lies-to-the-left-or-right-of-a-way.svg
--Cmuelle8 (talk) 18:34, 7 January 2016 (UTC)
Imagine this algorithm in a pixelised renderer (as every renderer eventually becomes).
   put all pixels on the ways in a queue
   For every pixel in the queue:
       colour the pixel
       if (pixel is on one line): // being on multiple lines, we need to ignore the point further.
           Get the angle from this point to the next node coordinate
           rotate the angle 90° counter-clockwise, and round to the closes 90° multiple // == left direction
           Add the next pixel in that direction to the queue (if not coloured)
       else if (pixel is on no lines):
           Add the non-coloured pixels in 4 directions to the queue
With some extra details (like only considering pixels in the bbox when working in a bbox, and taking the reverse flag into account) this would always give a correct rendering, even without knowing which rings are outer or inner or at what point in the nesting your bbox actually is. --Sanderd17 (talk) 20:11, 7 January 2016 (UTC)

discussion from january 8th on

No, what you do with this algorithm is colour one side of the area, but you do not know if this is the inside or the outside (without role info). However, we only want to colour the inside. --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
I guess you still don't get my area definition. I define the inside of the area to be the left side. So yes, I get the inside of the area. That inside can span quite a large area, and even go over map bounds. F.e. imagine the "inside" of the land area of Antarctica. Only the real coasline needs to be drawn, and the Web-mercator clipped poles and date line act as a bounding box. When you would define "inner" or "outer" on that area, there's no way to deduce the side to render as land. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
Here's the reason of our misunderstanding. You are arguing based on the premise of a way's direction never being altered after you've defined your area. Your area type depends on the way direction to stay the same after definition (or needs to alter/update all area objects if the way ever should be reversed (the way, not the rev-flags)). I silently tested your area definition for robustness (e.g. if it survives the case of a downloaded way changing its direction, without having areas depending on it in the clients dataset). See an extended version of the graphic above that is hopefully better for you to understand the concerns I raised. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
To grasp this visually, take both blue rects in the graphic above, and invert the roles of the rings; the inside of the area will now be on the other side, you have to toggle the reversed-flag. But then the rings in the blue rects are coded exactly like the green ones!? If you do not know the role of the rings, applying this algorithm will color correctly one side of the area. But it has randomly hit the inside or outside doing so. (Please do not get distracted by the fact that an area object consisting of two inner rings only, or an outer within an inner ring only is considered invalid, simply imagine the two rings depicted are two of many in an area, but the only two you downloaded.)
Again, the algorithm will always hit the inside, if holes are disallowed (or, of course, if there is only one ring defined), in that case you don't need role info. --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
Roles are not unknown, roles are just not needed for any algorithm to work correctly, so they don't need to be defined. Even with partial downloads. You should not add roles, but just use the left-right definition to determine which points are inside the area. This is also why coastline is oriented btw, so you can edit and render it partially without breaking it. The main disadvantage with coastline is that applying multiple tags is hard, as you need to apply them to all ways. So my proposal tries to combine the way-orientation advantage of coastline, with the single set of tags of a MP. It's very similar to Zverik's proposal, with the minor differences that my area type is more simple, and follows the current OSM convention better of referencing objects from top to bottom. But my main disadvantage is that the top area object may grow a lot when many members are added. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
I never claimed role info could replace left/right info. My claim was that it is needed in addition. But as the extended version of my graphic shows it is only true, if you want to be robust about ways arbitrarily changing their direction (way reversal, not rev-flag-reversal). If you take extra care to always update all areas depending on a way X, if way X changes direction, you're fine. You will need to install additional server side checks for this to work: If a changeset consists only of a single way X altering its direction, you need to find all area references to X in the database and update those. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
Also, be aware of the "winding count" polygon interior algorithm, given e.g. as technique 3 in 5-ways-to-draw-2d-shape-with-hole-in. We probably do not want to implement a polygon rendering algorithm ourselves, as toolkit (java2d, opengl, gdi, etc.) and hardware (gpu vs cpu) have optimized algorithms for these operations (probably implementing winding count or even-odd at some point). --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
If you want to use the winding-algorithm, you need to apply a small preprocessing step (I'm again ignoring the reverse flag for simplicity here): Find intersections of the ways in the area object with the bbox sides. For every intersection that goes from inside the bbox to outside the bbox, you can close the ring by following the bbox counter-clockwise until the next intersection point (which should be with a way that goes from outside to inside the bbox if the area is correct). When you have all rings closed, the winding algorithm (or any algorithm that uses nesting of rings) can be applied again. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
You will need to do this preprocessing step for the algorithm you supplied as well, else else if (pixel is on no lines): will color the whole viewport. But again, we should not extend our discussion to ways of filling polygons/paths. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
Slight change in topic: Aside from correct rendering an editor will need a working is_in operation, to determine if a click coord is contained by an area. Even if we use a rendering algorithm reliably colouring the inside, it would be inefficient to implement this op by checking if pixel@click_coord is coloured. We'd need to maintain a backbuffer for each area object in the viewport (as frontbuffer has insides overdrawn with other objects). If role info is known and eventually bbox sides are used to close missing ring parts, most toolkits can do it much better (e.g. using GeneralPath and its contains() method). --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
As explained above, you can close the bbox sides when you encode the inner as being a side of the way. When you have only "outer" and "inner" roles, there's no possibility to close the area correctly by following the bbox edges (believe me, I tried implementing this for the OsmAnd renderer, but always messed it up in some cases so it would render the negative, the only option was to download complete MPs). Just imagine a single way going through the middle of a bbox, and being tagged with "outer". You can even optimise some algorithms like that. When you have closed the rings, you send out a ray from the point you want to test (in any direction you want). You can analyse the first intersection of the ray with the way of the area. And by looking at the angle between the ray and the way (which depends on the orientation of the way), you can know if the point is inside our outside the area. You don't even have to analyse further intersections. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
Yes, see above. If you encode the inside as a side of way and way directions never change (read: never change without all referencing areas being changed also), this will work. Again, I did not claim having only outer/inner will work to decode partial data. I proposed to have it in addition. Additional role info is not redundant if you expect the area type to be robust against arbitrary direction changes of ways (i.e. without areas "getting notified" about such changes). --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
I agree with your points about the possibility to add server-side checks/better validation for new area types, but there is absolutely no reason this can't be added for MPs, now. "We have never put constraints on relations, so we can't do it for MPs." is completely made up :) - Because of the flexibility of MPs you can even refine them now, without breaking existing ones (even without breaking invalid existing ones part of the db): --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
But we have never put constraints on tags, see this page: Elements [There is no fixed dictionary of tags, but there are many conventions documented on this wiki...]. By having strict checks for MPs, we would suddenly add an exception to that Except when the tag type=multipolygon is set on a relation then the roles can only be outer and inner, and correctly nested, which brings you again in muddy waters, as what do you do with type=boundary, or other roles like subarea=*? Adding all those exceptions would make the format description a lot harder, and as a result, it would also make the validators a lot uglier (with many hard-coded tags in it). While a top-level switch between being an area and not being an area would really help the format definition and anyone using the definition. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
See, I do not oppose having a dedicated area type. I just say that we can alternatively promote a certain relation type (or more), already representing an area, by applying those rules to it, we would apply when introducing a dedicated type.
The problem is not a representation issue, its a validation issue. And that validation can be done using relation type or another top-level one, it does not matter.
For MPs we actually have the convention that only 'outer' or 'inner' are valid roles, but a convention is not a check/rule. Promoting some relations to do server-side checks comes in no way 'suddenly' and it does not fix relation tag sets to a dictionary of tags. (Roles are not tags, as tags consist of key and value.) The freedom to choose any tags on relations is continued, but if you've used that freedom to choose e.g. "type=multipolygon" you can't do/add certain things with/to its corpus.
E.g. to be wild, you could throw away the top-level type way and OSM would still work if a way is just represented by a relation with an ordered node list. We would not need rules for a relation of "type=way" if by convention it contains ordered node lists only, but having rules/checks server-side will help to not mess things up unintentionally.
With regard to your concerns about a blown up format description: Introducing a dedicated area type will just add to the format description on another end. As you will need to be backwards compatible for a long time, it does in no way diminish complexity. Ideally an area type should have been thought about when starting osm, but osm is not part of an ideal world :) --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
  • "I can't render parts of a MP correctly, because ring association is not known."
may be replied by "Append ring number to the role keyword." --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
Still, what do you do if only one unclosed way crosses your bbox? You may know the ring association in that case, but won't be able to render it.--Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
True, if you want to render partially downloaded MPs they of course need to encode all the information we discussed about for a dedicated type above. Since members of relations are restricted to one attribute only (the role), it is the role field we need to stuff all info into we need for that partial render capability.
Transporting your original approach we'd use 'reversed_N'/'not_reversed_N' (where N is ring number) as role values instead of 'outer'/'inner'. But such MPs will be vulnerable to way direction changes. Each parent-MP of a way X needs to be updated, just like area objects based on your proposal, if X changes direction (has its node list reversed). To make such MPs immutable to way direction changes also, we need to retain 'outer'/'inner' info in addition, e.g. by using role values like:
long form
  • 'reversed_N'
  • 'not_reversed_N'
 short form
  • 'reversed_N'
  • 'N'
 with N being odd for members of 'outer' rings and even for 'inner' ones
long form
  • 'outer_N'
  • 'inner_N'
 short form
  • 'N'
  • 'inner_N'
 with N being odd for 'reversed' members (inside left at area definition time) and even for not_reversed members
--Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
  • "Manual changes of roles with ring numbers of partially downloaded relations may invalidate the MP."
"If server side checking is done, the changeset will be rejected at upload time." --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
And then you need to download an entire continent to fix it? Partial editing should need to have the possibility to see you're correct without downloading it all. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
Yes, but that is the job of the editing software and from a servers perspective we don't know anything about that software. The editor could either constrain the user to only make changes that will not invalidate partial data or it could allow the user to make any changes (as is now). In latter case you download entire data and fix it (as is now); in former case the partial data you upload will pass server-side-checks and all is fine. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
  • "Many mappers do not get roles right or don't care about them."
"If MP is fully downloaded the editor can and should compute and fill these, including ordering. If not see above. If you work with partial data you need to know what you do, this is currently the case as well." --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
My ultimate goal is to have coastline just as an area object. That would mean the area object is designed well to handle all areas, no matter how big. It's also why I like Zverik's area type a lot, but I think he complicates things a bit by also allowing nodes directly, and I still haven't figured out if I can have a top-down reference without making the area object itself too big. No OSM mapper should ever have to download an entire continent when adding coastline. And including nodes directly in the area object may also be good when you have many simple areas (like a city with buildings). My area type would cause quite some unneeded objects there. --Sanderd17 (talk) 10:59, 9 January 2016 (UTC)
Imho, huge areas may either be defined by a rough boundary which keeps area objects small (but probably defines more ways than actually needed), or by a lot of tiny boundary ways which calls for recursion at some point to avoid single objects growing large.
  • Defining huge areas precisely, without recursion at some point will download a tremendous amount of area objects for each bbox.
  • Defining huge areas precisely, using recursion at some point might not download the area object itself, but guarantees you get a leaf of the tree it is made of - you must crawl to the right parent to edit tags, but to edit geometry you do not need the parent, the leaf is enough (unless of course way is reversed and our area objects are not immutable to such an operation).
  • Defining huge areas might not be needed in some cases after all, if we find a good query to compute it based on other data.
.. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
  • "Validating MPs invalidates current db data."
"If you only check the changesets uploaded, data will gradually transform into a valid state, being checked at times it eventually becomes part of a changeset. I.e. redundant role information that currently cannot be relied on will transform to truely be redundant. Only then it will be useful for partial downloads. In which case it is not redundant from a clients perspective."
.. --Cmuelle8 (talk) 17:23, 8 January 2016 (UTC)
I've used '<ring>' incorrectly in the markup below the cases in the graphic, it should be '<area>' instead (and each way forms a complete ring, that makes two ring children in 'area' containing one of the ways each) - I'll put up a version with corrected markup, but it does not change anything on the issue. fixed. --Cmuelle8 (talk) 18:19, 8 January 2016 (UTC)
The text fragments above and below the table in the last two graphics (first, second) were synchronized after it has become vivid that way direction changes should cascade in Sanderd17's area proposal. --Cmuelle8 (talk) 20:26, 9 January 2016 (UTC)
Building on your example of antarctica's coastline, it's easy to see that additional role info won't help to find the inside if only some ways forming the ring are known and those ways have changed direction since the area has been defined, without having updated the area also.
But I suppose it will help cases where an area is defined by more than one ring, and the bbox does not intersect all rings. In these cases, you can use additional outer/inner info to find inside after downloading additional data, such that a ring of an area is either fully known or not at all. So it won't guarantee area objects being fully immutable, but on a ring level at least. --Cmuelle8 (talk) 22:13, 9 January 2016 (UTC)
To sum things up: If it is ensured that all areas depending on a way are updated if that way changes direction, additional role info is not needed and redundant with your approach. But if area objects are vulnerable by way direction changes, additional role info will help finding inside for fully known rings. E.g. if an area consists of three or more rings
  • parts of two of them might be downloaded to a bbox,
  • way directions might have invalidated the inside coding of this area object in the meantime (we can use the timestamps of downloaded parts to find out),
  • then with role info known, we can reconstruct the inside after having completely downloaded just two of three (or more) rings.
If the timestamp check is negative, the parts are valid and you do not need to engage in fully downloading their rings. --Cmuelle8 (talk) 22:38, 9 January 2016 (UTC)
Actually you will not need to download the whole ring in any case, but only up to a connected part that's older than the area timestamp, as you can reconstruct/check rev-flags for newer ring parts (where way direction might have changed) from there. This will be the whole ring in the worst case only, when all parts are newer. So yes, in most cases it will be possible to correctly render partial data without downloading lots of additional data, even without asserting areas are updated on all way direction changes (like it is the case now for MPs). --Cmuelle8 (talk) 11:12, 10 January 2016 (UTC)
Glossary hints: In this discussion way direction changes refers solely to the possibility that a node list of a way is reversed. After such a change node traversal of the changed way is equal to reverse node traversal of the original way. --Cmuelle8 (talk) 14:42, 10 January 2016 (UTC)
If referential integrity is not assured (current case for server-side), there are other way operations that might invalidate area objects (split way, deleting start or end node). If after such operation a way end is still connected to an unmodified ring part, we can find inside for this way (although there will be a gap in the ring), but if both ends get disconnected we will have a member in the area definition we cannot automatically deduce an inside for. Whether or not to introduce referential integrity (server-side validation) for a revised area type will have a bigger impact on the future of areas than how it's stored (new "top-level" type vs. relation-based). --Cmuelle8 (talk) 16:52, 10 January 2016 (UTC)
Some of the things learned from this discussion are now summarized in The Future of Areas/Fixing Multipolygons. The article does not mandate an API change, so employing this without additional server-side changes will continue to not ensure referential integrity. But it is a more robust way to define areas compared to what's in use now. --Cmuelle8 (talk) 19:46, 11 January 2016 (UTC)

DE:Relation:multipolygon, Relation:multipolygon

Du hast in den vergangenen Wochen in größerem Umfang die Seiten DE:Relation:multipolygon und Relation:multipolygon bearbeitet. Deine Bearbeiten wurden in Teilen wieder zurückgesetzt.

Diese Seiten dokumentieren, wie Multipolygone in OSM "funktionieren". Bitte beachte, dass OSM nicht OGC-konform ist. Bitte versuche nicht, akzeptierte Standards durch editieren ihrer Wiki-Seiten heimlich zu modifizieren.

Deine Bearbeitungen sind Teil einer Diskussion im deutschen OSM-Forum. Du kannst dich dort mit deinem OSM-Account einloggen. --Nakaner (talk) 13:05, 9 February 2016 (UTC)

Was bitteschön ist an einem Wiki "heimlich"?? Ich habe die Seiten bearbeitet, weil sie inkorrekt sind. Und das ist nicht meine Meinung, sondern schlichte Mathematik, die in Openstreetmap nunmal tausendfach zur Anwendung kommt. Wenn mathematisch inkorrekte und vage Aussagen hier nicht verbessert und korrigiert werden dürfen, und die beste Übung der hier versammelten Wikipedianer das 'revertieren' geworden ist, dann ist das bestenfalls ein Problem, dem man nicht klein beigeben darf! Gruß --Cmuelle8 (talk) 17:10, 10 February 2016 (UTC)
Ich habe im Übrigen nie behauptet, dass OSM OGC-konform sein müsse und weiß folglich nicht, weshalb das (nicht nur von dir) unterstellt wird. Weiterhin ist das Markieren eines Faktums als Meinung, schlimmer noch als Einzelmeinung schlechter Diskussionsstil. Das ist rhethorischer "Feinsinn", der sonst in der Politik zu finden ist. Außerdem ist das Gegenteil deiner Aussage wohl schon dadurch bewiesen, dass das Thema rege diskutiert wird. Diese Diskussionen (im Forum und im Wiki) fänden wohl nicht statt, würde es sich um einen allerseits "akzeptierten Standard" handeln, wie du schreibst.
Hier geht es um Ingenieursthemen (ich zähle auch den/die OSM-Kartographen zu den Ingenieuren), die i.d.R. nach bestmöglichen Lösungen suchen und nicht nach irgendwelchen. Das Datenmodell von OSM ensteht evolutionär, d.h. es ist nicht ausgeschlossen, dass Widersprüche, Ecken oder Ungereimtheiten zu Änderungen führen (auch in sehr langen Zeitspannen), so wie das in der Vergangenheit bereits mehrfach der Fall war. Deshalb ist das Argument "das war schon immer so" nicht tragfähig!
Das beste Beispiel für die Zaglosigkeit solcher Anpassungen war der Lizenzwechsel und der fand, aus ingenieurstechnischer Sicht, wegen einer weit belangloseren Thematik statt.
Du hängst dich an der OGC-Verwendung von MPs auf. Es wäre ja kein schlechter Zufall, wenn eine halbwegs sinnvolle, die Topologie der Realität achtende Definition von Multipolygonen Konformität zu anderen Datenmodellen quasi zwanglos herbeiführt, weil sie eben Ableitungen der Realität sind und nicht x-beliebige Hirngespinste. OSM ist sehr darum bemüht, die Realität bestmöglich abzubilden. Ansonsten würden wir ja auch irgendwelche Fantasieinseln in der DB dulden.
Beschäftige dich am besten mit dem Artikel Best practices und dann überlege inwiefern die Artikel zu den Multipolygonen dem gerecht wurden/werden bzw. werden können. Bitte versuche nicht, Änderungen per se als Angriff oder feindselige Aktion zu interpretieren! Bitte versuche nicht, Leute von einer offenen Platform in eine andere zu bewegen! Das Forum dokumentiert Multipolygone nunmal nicht, also ist es auch nicht der geeignete Ort, um deren Dokumentation zu verbessern. Das Wiki besitzt Diskussionsseiten, um relevante Auseinandersetzungen kompakt beim Artikel zu halten und nicht irgendwo, in irgendwelchen anderen Sprachen, auf irgendwelchen Seiten, die womöglich gar nicht vom Projekt administriert werden. --Cmuelle8 (talk) 18:49, 10 February 2016 (UTC)
Vielleicht hilft Dir zum Verständnis meiner Änderungen bzgl. der Thematik sich berührender innerer Ringe auch mal ein Blick auf die Version des Abschnitts vom 15. Dezember letzten Jahres, denn dort wurde die Existenz dieses Sonderfalls in OSM auf eine inkorrekte Interpretation einer Textzeile zurückgeführt, die klar aus der OGC-Norm stammt. Zitat:
"In OpenStreetMap Standard ist das selbstverständlich vorgesehen: ... A MULTIPOLYGON is valid if and only if all of its elements are valid and the interiors of no two elements intersect. The boundaries of any two elements may touch, but only at a finite number of POINTs. ... "
Falls die Existenz des Sonderfalls nicht bzw. nicht allein auf dieser inkorrekten Interpretation basiert, stellt sich a) die Frage, weshalb dieser zitierte Abschnitt ohne Revert in der als Pseudo-Spezifikation verwendeten Dokumentation verblieb und b) weshalb es keinen brauchbareren Beleg für diese grundlegende "Design-"Entscheidung gibt. Z.B. wäre ein Verweis auf entsprechende Mailinglist- und/oder Foreneinträge angebracht, damit eine signifikante Mitgliederzahl des Projekts, die diese als klare Fehlentscheidung wertet, die ursächlichen Beweggründe nachvollziehen und prüfen kann (was im Übrigen evtl. auch ein Vorteil für die Befürworter wäre).
Ein akzeptierter Standard, wie Du dir das schönredest, ist es in diesem Punkt angesichts der Debatten jedenfalls nicht. --Cmuelle8 (talk) 00:36, 11 February 2016 (UTC)

Changes to bicycle pages

Hello.

We've noticed that you changed several pages that describe how to map cycleways, with the intention to replace tags such as cycleway=opposite_lane with a combination of tags such as cycleway:left=lane + cycleway:left:oneway=-1. I might miss some details but debating tags is not my point here.

My point is : what motivates this change to the Wiki ? Has it been discussed and where ? I cannot see any recent discussion about this in the Tagging list, which is where tag proposals and changes must be discussed. You indicate in your comments that this is legacy, so there must be some traces somewhere. Can you please point me at those traces.

Regards, Antoine.

You obviously miss the point. The intention is not to replace cycleway=opposite_lane which is a legacy tag and will continue to be accepted and used for long. The intention is to limit this value to exactly that key. cycleway:right=* and cycleway:left=* were introduced at a later point in time to OSM to fix problems with disambiguity. They absolutely need to be discriminant in specific aspects to be of any value. If you import the problematic values that these newer tags aimed to solve, you are effectively diluting their usefulness.
At the time they were introduced the legacy tagging was well established, so no attempt was made to convert all the values by an automated process. The newer tagging scheme co-existed aside the earlier one. At least they co-existed well until some genious decided to mix their values by mood.
There has been a reason, that opposite_lane has not been documented in the wiki pages for cycleway:right=* and cycleway:left=* - think about it. The documented values are/were cycleway:*=lane and cycleway:*=track and that meant exactly those two. You should rather ask yourself about the motivation to deliberately introduce inconsistency into the wiki documentation. I don't know at which point the wrongful use was introduced in the wiki, but its based on pure luck that it went by unnoticed and lived up to be perceived as a status quo in the meantime. --Cmuelle8 (talk) 11:30, 15 March 2019 (UTC)

Deprecation question

I encountered https://wiki.openstreetmap.org/w/index.php?title=Key:cycleway:left&diff=1820888&oldid=1532737 and I have question about it at https://wiki.openstreetmap.org/wiki/Talk:Key:cycleway:left#Why_opposite_lane_is_supposed_to_be_invalid_value.3F

Can you reply on that page? Mateusz Konieczny (talk) 06:17, 4 September 2020 (UTC)

Yes, done. --Cmuelle8 (talk) 20:36, 4 September 2020 (UTC)
Also read the paragraph above, maybe. Its old, but still valid. --Cmuelle8 (talk) 20:38, 4 September 2020 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the author of image File:Leipzig stop positions.png ?

Updated, but the information is probably outdated. --Cmuelle8 (talk) 09:18, 12 March 2022 (UTC)

User:Cmuelle8/Bicycle oneway scratchpad

User:Cmuelle8/Bicycle oneway scratchpad - is it intended as proposal or is it a test page than can be blanked? Mateusz Konieczny (talk) 11:16, 26 June 2022 (UTC)

It's a user page that's supposed to be left as is. Thanks. Don't dawdle on user pages on wikis in general, every other user will know that this is semi-official info. If you need to discuss on the subject matter, you have more than one option: either use the discussion page or start your own proposal. Also, if you think this is worth starting a proposal with, go ahead and create your own version in main namespace. Inactivity on user pages is not a signal to scrap things. In general, if other people with more energy in the meantime want to continue on inactive/old user drafts, it is not helpful for these pages to be blanked. They are part of the creative process, generally speaking. --Cmuelle8 (talk) 14:35, 28 June 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:Cmuelle8&oldid=2349256"