[Tagging] Power generation refinement: power plant model evolution

Martin Vonwald (imagic) imagic.osm at gmail.com
Mon Apr 8 05:45:39 UTC 2013


Am 08.04.2013 um 00:03 schrieb François Lacombe <francois.lacombe at telecom-bretagne.eu>:

> Hi again :)
> 2013/4/7 Martin Vonwald <imagic.osm at gmail.com>
>> Hi!
>> Actually how could that happen?
> I don't have example, I was only guessing.
> Assuming 2 different power plants with output generators in each (and links for power exchanges between both) would help us to solve that kind of issue.
> => All right, my objection was stupid!

Lets call it discussion, then it's not stupid anymore ;-)

>> I was about to suggest the same as Martin Koppenhöfer: additional tag on the generator itself. Putting the generators of a plant into categories (category A: output, category B: intermediate) by using a relation sounds to me like this: [1] .
> I'll update proposal with following generator tag values: generator=output or generator=intermediate (generator=* key doesn't exist).

I like readable tags. When I read generator=output I have no clue about its meaning. Every generator has output. So I definitively would add the word plant there anywhere.

> Thus all generators of a power plant would be added to an hypothetic power=plant relation with role=generator.
> This will be convenient to make the distinguishing on generator's tags and only there.

What could be the role of a generator if not generator? You wrote "all generators ... with role=generator" - so the role does not have any meaning. Then drop it.

Also: if I simply add all the perimeters of a multi-site plant to the relation, I don't need anything else in the relation. It would also be more robust. Think of Joe Mapper who adds a newly built substation within the perimeter of the plant. A relation was created earlier by a different mapper. Joe doesn't know/care about the relation so he only adds the substation. If the relation only contains the perimeters it is still complete and the new substation is now part of the plant. If the relation has to carry all of the features it is now broken.
And furthermore: how can we find such broken relations?

Of course if there is no clear perimeter (e.g. wind parks) the features themselves have to be added.

>> Same goes for the substations by the way.
> It's different for substations.
> No categorization for them.

My point was more like: if we have the perimeters we don't need this information about the substations. But see below!

> Nevertheless they could easily be placed off the perimeter of a single site power plant. How to make links in that particular case?

Is it still part of the plant?

> In France for instance, substations and power grid are operated by RTE and power plants by different companies.

So they are two different features. A plant and a substation.

> Have a look to Tricastin nuclear power plant (biggest one I mean) : http://goo.gl/maps/HcyIf
> Power plant perimeter is between Rhone river and publicly accessed road D459 with 4 reactor buildings. Substation is behind a private uranium  enrichment plant (big white buildings) which is not part of the power plant so we can't put a whole closed way around that stuff.

Does it really belong to the plant? Or is the "output" of the plant transferred to the substation outside of the plant, where it is further transformed? If you ask the operator of Tricastin if this is "their" substation, what would be their answer? And what would be the answer of RWE?

> I don't see anything else than a relation to bring substation and power plant together.

If they don't belong together they shouldn't be brought together ;-)

> You may say it's not a single site power plant.
> => Many situation like above would be encountered so we won't actually have so many single site power plant.
> => Only the substation is off the power plant site. Do we have to link substation and power plants this way?

See above. Two different operators might be a good clue that they don't belong to each other.

Best regard,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130408/eabda241/attachment.html>

More information about the Tagging mailing list