Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
On Sun, Nov 22, 2020 at 8:04 PM Brian M. Sperlongano wrote: > Therefore, a holistic solution is needed for large objects. Setting an > api limit is good because it gives consumers a guarantee about the > worst-case object they might have to handle. However, it must also be > combined with a replacement mechanism for representing large objects. The > 2,000 node limit for a way is fine because longer ways can be combined via > relations. If the relation member limit were capped, you create a class of > objects that cannot be represented in the data set. > We've already substantially solved that problem for routes. Super-relations seem to work well, and only rarely do we even need a three-level hierarchy. As Steve points out, we could go deeper, but there's no need. > > What I think is missing is a way to store huge multipolygons in such a way > that they can be worked with in a piecemeal way. The answer that > immediately comes to mind is a scheme where large objects are represented > as relations of relations, where portions of a huge multipolygon are > chopped up into fragments and stored in subordinate multipolygon > relations. This hierarchy could perhaps nest several levels if needed. > Now a 40,000 member relation could be composed of 200 relations of 200 > members each, with each subordinate relation member being a valid > multipolygon with disjoint or adjacent portions of the overall geometry. > > Then, an editor could say "here is a large relation, I've drawn bounding > boxes for the 200 sub-relations, if you select one, I'll load its data and > you can edit just that sub-relation". > > This could *almost* work under the current relation scheme (provided new > relation types are invented to cover these types of data structures, and > consumers roger up to supporting such hierarchical relations). The thing > that makes this fail for interactive data consumers (such as an editor or a > display) is that *there's no way to know where relation members are, > spatially, within the relation*. The api does not have a way to say > "what is the bounding box of this object?" A consumer would need to > traverse down through the hierarchy to compute the inner bounding boxes, > which defeats the purpose of subdividing it in the first place. > You're right that it's a problem, but you misdiagnose the details. Rather than identifying bounding boxes, which is easy, the problem comes down to identifying topology - is a given point in space on the inside or outside of the multipolygon? The minimal information needed when that question is asked is one of two things. You need to know either the 'winding number' - essentially, if you draw a mathematical ray from the point to infinity in a given direction, how many times do you cross the boundary of the region? (Odd = inside, even = outside). The second is to add a requirement to the data model that the boundaries of regions must follow a particular winding direction; most GIS systems use the "right hand rule" of specifying that as you proceed along a boundary way, the interior of a relation should be on your right. The second rule is by far the easiest to implement. Unfortunately, it's also inconsistent with OSM's base data model. The problem is that we do not necessarily require multipolygons to be sorted in any particular order (depending on client software to order them if necessary), nor do we require the boundary ways to proceed in any particular direction with respect to the multipolygon. In fact, we cannot require the boundary ways to proceed in a particular direction, since shared ways between adjacent multipolygons are a fairly common practice. The practice is somewhat controversial; nevertheless, it seems like a good idea when the adjoining regions by their nature are both known to touch and known to be mutually exclusive. The lines that separate landuse from landuse, landcover from landcover, administrative region from administrative region, land from water, or cadastral parcel from cadastral parcel (where cadastre is accepted, as it is with objects like public recreational land). Except for monsters such as the World Ocean (the coastline is a perpetual headache), seas, and objects with extremely complex topology, the problem is somewhat manageable. A single 'ring' (the cycle of contiguous ways, inner or outer, that form one region of a multipolygon) or a single 'complex polygon' (an outer way and any inner ways subordinate to it) are generally quite manageable in terms of data volume. I can edit shorelines of the Great Lakes, for instance, with some confidence, by loading into JOSM all the data near the single stretch of shoreline that I'm working on, plus the entire outer perimeter of the lake (using the 'download incomplete members' function); having the shoreline outside the immediate region of interest doesn't stress the memory even of a somewhat obsolete laptop computer. Not all editors are as competent with managing large relations
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Brian, as someone who worked on these national rail relations (and still does, to some extent, though only around the edges), I agree with you that "very large" relations (in Amtrak we say that one route is >2500 relations and meets that standard of "very large") do exist. And, they are unwieldy, especially for those who edit with "only" moderate (or less!) compute resources. Such demands are partly why open mapping didn't happen until the 21st century: our computers are just keeping up (as they do: compute power fills niches of computing that the tech / hardware / software development only catches up to, it then begins to be used for those applications). Desktop computers and Java / early JOSM / Potlatch 1 and 2 around 2005 were an OK match for each other. OSM has grown these from there. (Nicely, in my opinion, though there are always newer, faster technologies and software platforms to harness them). AI on "bigger iron" is real today with what Facebook is doing in OSM with its machine learning toolchain. Data structures must keep up. Physics had to look to the ancients and see that 10 to the 100th power wasn't so big, there are Sanskrit words from long ago for what we consider fairly large numbers today. And so OSM must keep up with inventing its future (of data structures) capable of "keeping up with Earth as data." Super-relations do seem the way to go: so far, so good. I don't know about "200 deep" but as things go much wider (but not much deeper than perhaps several "relation-levels" for now, let's say "great-great-grandparents" I can hold in my mind for now), they seem like they will suffice. If we need that many "dimensions" (relations "deep," not necessarily wide, as data simply ARE wide, not necessarily deep, though we should be prepared to go deep if we need to) we can, as you say "go hundreds deep." But yes, doing so both preserves the legacy of relations of relations (and even "of relations...ad infinitum") we don't need to do that very often. However, in train routes, there are now super-routes that exist that are "grandparents," so three deep. This seems to be happening with bicycle routes, too and perhaps road routes, I'm not quite enough of a road geek to say yes or no, but I think so. Luckily, relational databases (like OSM) give us ways to link them all together, "walking up and down the chain of hierarchy." Some software, use cases, routers, whatever...will be sophisticated to do this walking and "be smarter for doing so," presenting a much fuller, richer, complete universe of data, some (software) will not and will present a more "flat" view of the world (OSM's data, really, similar to looking at ways or nodes only but ignoring relations). We both have and use methods to do this, so, "good." But you are right to be talking about it, as data consumers, use cases, "those downstream" will need to have their antennae tuned to be paying attention to these "more sophisticated" ways of embedding hierarchy in our data. We have been doing this since relations were developed in OSM, some data consumer softwares pay attention, some don't. It's a real thing. I like, for example, the way that Lonvia (in the www.waymarkedtrails.org series of overlay layers) allows and displays a view of relations and super-relations in the table of routes presented. That's called "paying attention" and it's great when developers pay attention to these richnesses in the structure of our (sometimes hierarchical) data (so, thank you again, Sarah). Being aware there IS a hierarchy is the first step to "walking it" and presenting its complexity to data consumers in ways that make sense for that sort of structure. We'll solve coastline / water edges, it'll be mostly legacy (we've done it like this for quite some time) with a bit of "new methods of thinking about things" going forward. This is how OSM works. Talking about it is fine. We're generating light, not heat. A lot of people (Simon, Phake, Dave F, Clay, Mateusz, Christoph, Brian, Seth, Richard, more...) are quite right here. Let's listen to each other. We're all much MORE in agreement than disagreement. SteveA ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
As time goes on, we will encounter increasingly accurate and resolute mechanisms for surveying things like coastlines and land cover. For example, there are discussions about whether to use things like AI and machine learning to produce such data. The demand for ways to deal with larger objects will only grow in the future Therefore, a holistic solution is needed for large objects. Setting an api limit is good because it gives consumers a guarantee about the worst-case object they might have to handle. However, it must also be combined with a replacement mechanism for representing large objects. The 2,000 node limit for a way is fine because longer ways can be combined via relations. If the relation member limit were capped, you create a class of objects that cannot be represented in the data set. What I think is missing is a way to store huge multipolygons in such a way that they can be worked with in a piecemeal way. The answer that immediately comes to mind is a scheme where large objects are represented as relations of relations, where portions of a huge multipolygon are chopped up into fragments and stored in subordinate multipolygon relations. This hierarchy could perhaps nest several levels if needed. Now a 40,000 member relation could be composed of 200 relations of 200 members each, with each subordinate relation member being a valid multipolygon with disjoint or adjacent portions of the overall geometry. Then, an editor could say "here is a large relation, I've drawn bounding boxes for the 200 sub-relations, if you select one, I'll load its data and you can edit just that sub-relation". This could *almost* work under the current relation scheme (provided new relation types are invented to cover these types of data structures, and consumers roger up to supporting such hierarchical relations). The thing that makes this fail for interactive data consumers (such as an editor or a display) is that *there's no way to know where relation members are, spatially, within the relation*. The api does not have a way to say "what is the bounding box of this object?" A consumer would need to traverse down through the hierarchy to compute the inner bounding boxes, which defeats the purpose of subdividing it in the first place. On Sun, Nov 22, 2020 at 1:44 PM Simon Poole wrote: > > Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano: > > .. > > > > I like the idea of an api limit, though we would need a strategy to > > deal with existing large objects. > > .. > > This is, "surprise", not a new topic. There are certain issues with the > semantics of relations which make this slightly more involved as the > maximum node limit on ways. > > See > > - https://github.com/openstreetmap/openstreetmap-website/issues/1711 > > - https://github.com/zerebubuth/openstreetmap-cgimap/pull/174 > > With the later giving some insights in to why simply declaring a limit > is not a good idea. But putting a bound in place and expecting all tools > to be handle relations up to that size (just as we currently do with > ways) would be a good thing to improve robustness of the whole system. > > Simon > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
> Mateusz Konieczny via Tagging hat am 22.11.2020 > 20:49 geschrieben: > > > https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html > Yes, long time ago there was a problematic idea that was abandoned. Exactly. It also shows how we in OSM traditionally make decisions about tagging. An idea to change tagging practice was suggested - on an open channel for everyone to read and comment on without hurdles and with an archive that allows us now to read up on things years later. It was discussed and arguments and reasoning were provided both for and against the idea and based on that we reached consensus that it was a bad idea and it was abandoned. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?
sent from a phone > On 22. Nov 2020, at 18:47, Seth Deegan wrote: > > I agree with Dave F. > > It's a duplicate. I also agree with Dave F., it is not a suitable surface value, nor is it a duplicate of “surface= wood” Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Nov 22, 2020, 19:00 by tagging@openstreetmap.org: > I'm surprised you think that as you were a contributor to the discussions: > > https://github.com/gravitystorm/openstreetmap-carto/pull/3102 > This is a closed, not implemented PR. So it is not a case of "OSM-carto demanding boundaries on ways". > https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html > Yes, long time ago there was a problematic idea that was abandoned. Describing something like that over two years later as "OSM-carto demanding boundaries on ways" - in present tense and with claim that it is technical issue caused by incompetent programmers is misleading at best. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Nov 22, 2020, 19:34 by tagging@openstreetmap.org: > > > On 22/11/2020 18:12, Clay Smalley wrote: > >> On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging <>> >> tagging@openstreetmap.org>> > wrote: >> >>> >>> >>> Contributing to the database (also *volunteers*) are expected >>> to map to a certain standard. There shouldn't be a reason to >>> expect develops not to do the same. >>> >> >> If it's so easy, why don't you write the "few lines ofcode" >> necessary to fix this issue? >> > I did. Note the response. > > > https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636 > The mention was about "few lines ofcode" necessary to fix this issue Not about lines of code making something similar on a different software stack, that is not fixing the issue at all. And the very next comment is > Exactly, however there is no way to express that in CartoCSS. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Excuse me, what is the limitation here against tagging "Extremely long Amtrak relations"? Some of those Amtrak services, while long, in my knowledge are still far from the longest in the OSM database, like they're shorter than the train route between Moscow to Pyongyang, which have been tagged as a regular relationship with no observable problem to me. In my opinion, since these long Amtrak service are still just a single services, with no break or cha.ge of train or change of train number in-between, it seems outright bogus to tag them separately, and would confuse anyway who wish to use OSM data to provide navigation involving such train routes. 在 2020年11月22日週日 19:29，Richard Fairhurst 寫道： > [cross-posted to talk-us@ and tagging@, please choose your follow-ups > wisely] > > Brian M. Sperlongano wrote: > > It seems that we are increasingly doing things to simplify the > > model because certain tooling can't handle the real level of > > complexity that exists in the real world. I'm in favor of fixing > > the tooling rather than neutering the data. > > I sincerely hope "I'm in favor of fixing" translates as "I'm planning to > fix", though I fear I may be disappointed. > > More broadly, we need to nip this "oh just fix the tools" stuff in the > bud. > > OSM optimises for the mapper, because mappers are our most valuable > resource. That's how it's always been and that's how it should be. > > But that does not mean that volunteer tool authors should rewrite their > tools to cope with the 0.1% case; nor that it is reasonable for mappers to > make stuff ever more complex and expect developers to automatically fall in > line; nor that any given map has a obligation to render this 0.1%, or > indeed, anything that the map's creator doesn't want to render. > > The Tongass National Forest is not "in the real world", it is an > artificial administrative construct drawn up on some bureaucrat's desk. > It's not an actual forest where the boundaries represent a single > contiguous mass of trees. Nothing is lost or "neutered" by mapping it as > several relations (with a super-relation for completeness if you insist), > just as nothing is lost by tagging Chesapeake Bay with the series of > letters "c","o","a","s","t","l","i","n" and "e". > > Richard > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano: .. I like the idea of an api limit, though we would need a strategy to deal with existing large objects. .. This is, "surprise", not a new topic. There are certain issues with the semantics of relations which make this slightly more involved as the maximum node limit on ways. See - https://github.com/openstreetmap/openstreetmap-website/issues/1711 - https://github.com/zerebubuth/openstreetmap-cgimap/pull/174 With the later giving some insights in to why simply declaring a limit is not a good idea. But putting a bound in place and expecting all tools to be handle relations up to that size (just as we currently do with ways) would be a good thing to improve robustness of the whole system. Simon OpenPGP_0x4721711092E282EA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
On 22/11/2020 18:12, Clay Smalley wrote: On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging mailto:tagging@openstreetmap.org>> wrote: Contributing to the database (also *volunteers*) are expected to map to a certain standard. There shouldn't be a reason to expect develops not to do the same. If it's so easy, why don't you write the "few lines of code" necessary to fix this issue? I did. Note the response. https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636 Desiring relations to list in their entirety is *not* a "0.1% case". Splitting them into 'super relations' should not be the desired, final solution. Amtrak routes, like many other public transit routes, are already split into super-relations (see [1], [2]). Yes. I've done it myself on UK bicycle routes, but only out of necessity, due to the software limitation, not, as I stated, from any desire. It would be much less error prone with tags & ways being added to the wrong relations. DaveF ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging < tagging@openstreetmap.org> wrote: > On 22/11/2020 11:24, Richard Fairhurst wrote: > > > I sincerely hope "I'm in favor of fixing" translates as "I'm planning to > fix", though I fear I may be disappointed. > > More broadly, we need to nip this "oh just fix the tools" stuff in the > bud. (etc) > > > Likewise we need to stop software developers from expecting contributors > to add data purely because they can't be bothered/not competent enough to > write a few lines of code. (OSM-carto demanding boundaries on ways & > numerous routers expecting multiple foodways to criss-cross pedestrian > areas, are just two examples) > > Contributing to the database (also *volunteers*) are expected to map to a > certain standard. There shouldn't be a reason to expect develops not to do > the same. > If it's so easy, why don't you write the "few lines of code" necessary to fix this issue? > Desiring relations to list in their entirety is *not* a "0.1% case". > Splitting them into 'super relations' should not be the desired, final > solution. > Amtrak routes, like many other public transit routes, are already split into super-relations (see [1], [2]). This is a non-issue. I've already decided to split up long-distance Amtrak routes into more manageable chunks, especially since I'm the one who takes on most of the work of managing them. My original question was *how* to split them up, not *whether* to split them. I'm not convinced that attempts to persuade me not to do so are helpful in any way, so I'm going to consider them off-topic and ignore them. -Clay [1] https://wiki.openstreetmap.org/wiki/Relation:route_master [2] https://wiki.openstreetmap.org/wiki/Amtrak ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
I'm surprised you think that as you were a contributor to the discussions: https://github.com/gravitystorm/openstreetmap-carto/pull/3102 https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html DaveF On 22/11/2020 16:32, Christoph Hormann wrote: Dave F via Tagging hat am 22.11.2020 17:08 geschrieben: [...] OSM-carto demanding boundaries on ways ??? I am smelling fake news here. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?
I agree with Dave F. It's a duplicate. On Sat, Nov 21, 2020 at 7:43 PM Dave F via Tagging < tagging@openstreetmap.org> wrote: > To me, boardwalk describes the design & appearance rather than the surface > construction: An elevated walkway. > Although I do admit that's mostly influenced by The Drifters song. > > DaveF > > > On 21/11/2020 23:20, Mateusz Konieczny via Tagging wrote: > > Is there some value in surface=boardwalk tag? > > It seems to be a duplicate of surface=wood. > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Thanks, Seth ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Nov 22, 2020, 17:08 by tagging@openstreetmap.org: > Likewise we need to stop software developers from expectingcontributors > to add data purely because they can't be bothered/notcompetent enough to > write a few lines of code. (OSM-carto demandingboundaries on ways) > [citation needed] for OSM-carto demandingboundaries on ways Also [citation needed] for OSM-Carto support for boundary relations being extremely easy to implement > & numerous routers expecting multiplefoodways to criss-cross pedestrian > areas, are just two examples) > Also [citation needed] for that reason is "can't be bothered/notcompetent enough to write a few lines of code" > If developers are offended at receiving suggestions on how toimprove > their software, or even have it criticized, then they shouldrescind it. > If you insult others, claim that something is trivial to implement (it is not), while something you demand is implemented already and suggest that anyone offended by your comments should stop releasing software I would say that it is quite poor way to encourage volunteer contributors to implement what you want. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
I agree. I removed such duplicate tagging from my area some time ago, and it has not affected anything. I even went so far as to draft a proposal to change that recommendation. https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members On Sun, Nov 22, 2020, 11:37 AM Christoph Hormann wrote: > > > > Dave F via Tagging hat am 22.11.2020 17:08 > geschrieben: > > > > [...] OSM-carto demanding boundaries on ways > > ??? > > I am smelling fake news here. > > -- > Christoph Hormann > http://www.imagico.de/ > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
Super relations could also solve problems like the Tongass National Forest. By crafting a relation of relations, you still preserve the ability to have one tagged super-object represent one complex thing in real life, but with natural cut points so that any consumer can choose to deal with in in manageable stages. No different from the 2000 node limit on ways. There should still be a top level object that represents the whole thing. I like the idea of an api limit, though we would need a strategy to deal with existing large objects. On Sun, Nov 22, 2020, 11:24 AM Seth Deegan wrote: > I recently found out about the Extremely long Amtrak route relations from > clay_c. > > Your message is a bit confusing at first but I think you are proposing > that relations and super-relations should be used more-often to reduce the > complexity of processing data for data consumers? > > In that case, I would support an API limit on the number of members in a > relation. > I agree that developers shouldn't have to handle this burden. > > In response to DaveF's comment: > >> Actually, splitting way because software can't handle it, is making the >> database more complex. > > > Yes, but benefits outweigh the costs. > If the editors did this automatically and still made the data > interpretable, this wouldn't be an issue. > > Sorry if I misinterpreted the conversation. > > On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst > wrote: > >> [cross-posted to talk-us@ and tagging@, please choose your follow-ups >> wisely] >> >> Brian M. Sperlongano wrote: >> > It seems that we are increasingly doing things to simplify the >> > model because certain tooling can't handle the real level of >> > complexity that exists in the real world. I'm in favor of fixing >> > the tooling rather than neutering the data. >> >> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to >> fix", though I fear I may be disappointed. >> >> More broadly, we need to nip this "oh just fix the tools" stuff in the >> bud. >> >> OSM optimises for the mapper, because mappers are our most valuable >> resource. That's how it's always been and that's how it should be. >> >> But that does not mean that volunteer tool authors should rewrite their >> tools to cope with the 0.1% case; nor that it is reasonable for mappers to >> make stuff ever more complex and expect developers to automatically fall in >> line; nor that any given map has a obligation to render this 0.1%, or >> indeed, anything that the map's creator doesn't want to render. >> >> The Tongass National Forest is not "in the real world", it is an >> artificial administrative construct drawn up on some bureaucrat's desk. >> It's not an actual forest where the boundaries represent a single >> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as >> several relations (with a super-relation for completeness if you insist), >> just as nothing is lost by tagging Chesapeake Bay with the series of >> letters "c","o","a","s","t","l","i","n" and "e". >> >> Richard >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Thanks, > Seth > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
> Dave F via Tagging hat am 22.11.2020 17:08 > geschrieben: > > [...] OSM-carto demanding boundaries on ways ??? I am smelling fake news here. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
I recently found out about the Extremely long Amtrak route relations from clay_c. Your message is a bit confusing at first but I think you are proposing that relations and super-relations should be used more-often to reduce the complexity of processing data for data consumers? In that case, I would support an API limit on the number of members in a relation. I agree that developers shouldn't have to handle this burden. In response to DaveF's comment: > Actually, splitting way because software can't handle it, is making the > database more complex. Yes, but benefits outweigh the costs. If the editors did this automatically and still made the data interpretable, this wouldn't be an issue. Sorry if I misinterpreted the conversation. On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst wrote: > [cross-posted to talk-us@ and tagging@, please choose your follow-ups > wisely] > > Brian M. Sperlongano wrote: > > It seems that we are increasingly doing things to simplify the > > model because certain tooling can't handle the real level of > > complexity that exists in the real world. I'm in favor of fixing > > the tooling rather than neutering the data. > > I sincerely hope "I'm in favor of fixing" translates as "I'm planning to > fix", though I fear I may be disappointed. > > More broadly, we need to nip this "oh just fix the tools" stuff in the > bud. > > OSM optimises for the mapper, because mappers are our most valuable > resource. That's how it's always been and that's how it should be. > > But that does not mean that volunteer tool authors should rewrite their > tools to cope with the 0.1% case; nor that it is reasonable for mappers to > make stuff ever more complex and expect developers to automatically fall in > line; nor that any given map has a obligation to render this 0.1%, or > indeed, anything that the map's creator doesn't want to render. > > The Tongass National Forest is not "in the real world", it is an > artificial administrative construct drawn up on some bureaucrat's desk. > It's not an actual forest where the boundaries represent a single > contiguous mass of trees. Nothing is lost or "neutered" by mapping it as > several relations (with a super-relation for completeness if you insist), > just as nothing is lost by tagging Chesapeake Bay with the series of > letters "c","o","a","s","t","l","i","n" and "e". > > Richard > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Thanks, Seth ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
On 22/11/2020 11:24, Richard Fairhurst wrote: [cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] If you go against the accepted principle of not X-posting on a newsgroup, you've no entitlement to lecture how others respond. Brian M. Sperlongano wrote: > It seems that we are increasingly doing things to simplify the > model because certain tooling can't handle the real level of > complexity that exists in the real world. I'm in favor of fixing > the tooling rather than neutering the data. Actually, splitting way because software can't handle it, is making the database more complex. I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", though I fear I may be disappointed. More broadly, we need to nip this "oh just fix the tools" stuff in the bud. (etc) Likewise we need to stop software developers from expecting contributors to add data purely because they can't be bothered/not competent enough to write a few lines of code. (OSM-carto demanding boundaries on ways & numerous routers expecting multiple foodways to criss-cross pedestrian areas, are just two examples) Contributing to the database (also *volunteers*) are expected to map to a certain standard. There shouldn't be a reason to expect develops not to do the same. Desiring relations to list in their entirety is *not* a "0.1% case". Splitting them into 'super relations' should not be the desired, final solution. If developers are offended at receiving suggestions on how to improve their software, or even have it criticized, then they should rescind it. DaveF ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Pumping proposal
Hi Martin, Yves Usage is a good point, thank you. Le dim. 22 nov. 2020 à 03:01, Martin Koppenhoefer a écrit : > this would deprecate around 20k pump values describing a pump type, plus > 15k yes/no. > OSM counts 143k water_wells according to taginfo for man_made=water_well. There are 21k pump occurrences associated with those wells, which means 86% of them still wait to be completed with pump information. I don't blame anyone for not completing wells quick enough. 20k occurrences should be put into perspective of the global feature population. My small and domain-focused experience shows that such a change could encourage mappers to increase a lot the amount of described features more quickly. https://www.openstreetmap.org/user/InfosReseaux/diary/391058 tower:type=suspension january 2013 => september 2019 : 25k occurrences peak tower:type=anchor january 2013 => september 2019 : 13k occurrences peak line_attachment=suspension (exact replacement) july 2019 => december 2020 : 23k occurrences line_attachment=anchor (exact replacement) july 2019 => december 2020 : 21k occurrences Like many other successful moves done by dozens of volunteers. > Looking at the no-values, 23% are not in combination with man_made > https://taginfo.openstreetmap.org/tags/pump=no#combinations > i.e. this is also used on other objects to state buildings there is no > pump. > It's a good point to mention: pump word is actually used elsewhere, which sounds incorrect according current wiki I intend to extend https://wiki.openstreetmap.org/wiki/Key:pump requires : man_made=water_well All the best François ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extremely long Amtrak route relations / coastline v. water
[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] Brian M. Sperlongano wrote: > It seems that we are increasingly doing things to simplify the > model because certain tooling can't handle the real level of > complexity that exists in the real world. I'm in favor of fixing > the tooling rather than neutering the data. I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", though I fear I may be disappointed. More broadly, we need to nip this "oh just fix the tools" stuff in the bud. OSM optimises for the mapper, because mappers are our most valuable resource. That's how it's always been and that's how it should be. But that does not mean that volunteer tool authors should rewrite their tools to cope with the 0.1% case; nor that it is reasonable for mappers to make stuff ever more complex and expect developers to automatically fall in line; nor that any given map has a obligation to render this 0.1%, or indeed, anything that the map's creator doesn't want to render. The Tongass National Forest is not "in the real world", it is an artificial administrative construct drawn up on some bureaucrat's desk. It's not an actual forest where the boundaries represent a single contiguous mass of trees. Nothing is lost or "neutered" by mapping it as several relations (with a super-relation for completeness if you insist), just as nothing is lost by tagging Chesapeake Bay with the series of letters "c","o","a","s","t","l","i","n" and "e". Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] coastline v. water
Hi, On Sat, Nov 21, 2020 at 07:09:45PM +, Eric H. Christensen via Tagging wrote: > You cannot point to other area that may, in fact, be improperly mapped as an > example when they are like that because locals have been shouted down for > doing it correctly. The fact that this keeps coming back up literally means > that there is not universal agreement that "marginal seas", whatever that > means, are to be mapped with natural=coastline. > > The Chesapeake Bay is an estuary that, by definition, opens to the sea. It > can't be a sea and open to a sea at the same time. In this environment, it is > different from the ocean in which it opens into and is also different from > the tributaries that feed it. These are protected waters for ships. You won't > find any high seas forecasts for the Bay unlike the ocean. The Bay is also > brackish and not defined as salt water, unlike the ocean. There is a very fundamental misunderstanding on how OpenStreetMap works in here. The definition of a tag comes from the agreed-on understanding of the OpenStreetMap community as a whole of what that tag should be. This may or may not agree with defintion of the same word in other contexts. That's just the way it is with defintions. They may differ. You cannot just uniterally apply a definition of coastline that you think is more appropriate, or scientifically correct or whatever and change the map. It is OSM's definition that counts, and OSM's defintion only. That doesn't mean that definitions can't evolve over time but that needs to be discussed when it has a larger impact. natural=coastline is a particular touchy tag here because it is one of the few tags where we rely on a agreed-on definition that works on a planet-scale. Even if you change something relatively locally, it has an effect on how the planet map as a whole is rendered. You can't just apply a new definition to one bay. We must agree on a new definition globally here and apply it globally or the tagging becomes a worthless mess. So please, by all means, start a discussion about a new definition of coastline, make a wiki page, put it up for voting. But all this should be done **before** making any larger changes. For now, please, put the Chesapeake Bay back into its original state. Kind regards Sarah > ‐‐‐ Original Message ‐‐‐ > On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg > wrote: > > > Eric, > > I don't think the previous discussion is quite as inconclusive as your > > evaluation. > > > > While it is true that there is not widespread agreement on where the > > natural=coatline ways should transect a river mouth or river estuary, there > > is nearly universal agreement that marginal seas, including bays, are > > mapped with the natural=coastline. > > > > Using the rendering at https://www.openstreetmap.de/karte.html - which > > differentiates the marine water polygons outside of the coastline from > > lakes and rivers, by using slightly different colors, we can see how bays > > are mapped in other parts of North America and the world. > > > > For example, check out Delaware Bay, just up the coast from your area: > > https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000 > > - it is mapped as a natural=bay with natural=coastline around it, not > > natural=water > > > > Upper and Lower New York Bay are mapped as bays outside of the > > natural=coastline - you can see the line where the waterway=riverbank area > > starts just at the north end of Manhattan island (though this placement is > > somewhat controversial) - > > https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000 > > > > Tampa Bay: > > https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000 > > - outside of the natural=coastline > > > > Galveston Bay: > > https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT > > - outside of the natural=coastline > > > > San Francisco Bay and connected bays: > > https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT > > - outside of the coastline > > > > Puget Sound - while Lake Washington on the east side of Seattle is > > natural=water, also most of the ship canal connecting them: > > https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000 > > > > I would like to request that the tidal channels and estuaries around > > Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the > > natural-water polygons for the estuaries that is not a problem. > > > > But it would be contrary to normal practice to map the main body of > > Chesapeake Bay as natural=water because it is clearly part of the sea - > > there is no barrier between it and the open ocean, since there is an open > > channel through US 13 where the tunnel is. While it is an estuary by > > hydrological definitions, so are the Baltic Sea and all fjords and Puget > > Sound and San Francisco Bay - all of which are mapped as
Re: [Tagging] Feature Proposal - Voting - Pumping proposal
Given the number exposed here by Martin, and the fact that there is a few established data consumers, I think that preserving the pump tag as it is now and refine it with another tag would be a good idea indeed. Yves Le 22 novembre 2020 02:58:07 GMT+01:00, Martin Koppenhoefer a écrit : > > >sent from a phone > >> On 22. Nov 2020, at 02:32, François Lacombe >> wrote: >> >> It's true proposed tagging deprecates the current pump=* definition >> according to rationale and wishes to use the pump word in a more appropriate >> way. > > >this would deprecate around 20k pump values describing a pump type, plus 15k >yes/no. > >Looking at the no-values, 23% are not in combination with man_made >https://taginfo.openstreetmap.org/tags/pump=no#combinations >i.e. this is also used on other objects to state buildings there is no pump. >I would also suggest you modify your proposal in a way that it is compatible >with the current use of the pump tag > >Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
