Hi Martin, I must agree with you about the lack of simplicity of this relation-based model. I've been looking for a better and simpler model before updating the proposal (because I'm not a big fan of relations since it's an abstract object and we don't see them on maps), without success.
Even if the spatial DB allows us to compute closed ways to get what is inside, we don't have any distinguishing element associated to all that stuff. Mainly, dealing with intermediate and output generators requires to know what role is associated to each generator. Since all generators are tagged with power=generator, I don't see anywhere else than in the role of a relation member to write down this piece of information. Using power=generator for all generators is mandatory because generators can be found outside a power plant (for domestic devices for instance) and having many power=* values would force us to define source/method/types for each. If you can explain how integrate that kind of needs in a non-relation world, I think no one would mind (me first) a relations-free architecture. I'm ok to lighten the mappers' work but not to sacrifice tagging functionality. Furthermore, relational model is optional and may be used by experienced users only. I wish everyone a nice Sunday, cheers. 2013/4/6 Martin Vonwald <imagic....@gmail.com> > Hi! > > > 2013/4/6 François Lacombe <francois.laco...@telecom-bretagne.eu> > >> Looks fine, but why do we need a relation for single-site facilities >>> (examples Fukushima and Themis)? A site-relation is usually only necessary >>> if not all features of the "site" are within one closed area, i.e. they >>> are dispersed. I would strongly recommend keeping it this way. >>> >> >> I agree with such a point of view. >> Nevertheless relations allow us to link generators to the power plant >> where they're located in. >> They enable automatic rate computation by adding all individual >> generators' power for instance. >> >> Even if power plant is a single site infrastructure, it may be divided >> between several buildings and no link would easily be made between >> generators and power plant output. >> > > That's exactly my point: if one suggest to use a relation even for a > single site infrastructure, he suggest to put the workload from the > consumer to the mapper and that's the wrong way. We have a spatial > database: if there's a closed way surrounding all the feature you simply > don't need a relation to get all the features within, all you need is the > closed way. Yes, it is more complicated for the consumer. Yes, it needs > more processing. But it is (much) more robust, (much) better visible and > easier for the mapper. So do not suggest to put features of a single site > into a relation (as you do in some examples). OSM is getting complicated > enough. Scaring off new mappers with unnecessary complex schemes doesn't > help OSM, it hurts it. > > Sorry for those clear words, but we have to keep the bar low for mappers. > The ones who process our data usually have far more experience than the > average mapper. Put the burden on that end that can handle it. > > Best regards, > Martin > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > > -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
