[Tagging] Power generation refinement: power plant model evolution

François Lacombe francois.lacombe at telecom-bretagne.eu
Sun Apr 7 14:34:28 UTC 2013


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.osm at gmail.com>

> Hi!
>
>
> 2013/4/6 François Lacombe <francois.lacombe at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130407/d3b691a1/attachment.html>


More information about the Tagging mailing list