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 <jayands...@gmail.com> 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 <rich...@systemed.net> > 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
