Proposal talk:PipelineExtension

From OpenStreetMap Wiki
Jump to navigation Jump to search

(no longer) On Hold


a discussion with an expert from a major austrian pipeline operator has raised some valid security concerns. discussion is still going on, decisions have yet to be made; until then this proposal is on hold.--Rfuegen (talk) 13:44, 11 December 2013 (UTC)

Hi Rfuegen, Its been 6 months, so please could you give some update on where the discussions have got to:
Which features are the controversial ones, and is it possible for you to make a simplified version of the proposal?
Or is this an issue localised to Austria - so the proposal is ok but there will be no more pipeline mapping in Austria?
--Martin2014 (talk) 11:04, 30 May 2014 (UTC)

status update/1

here is a summary of an extensive phone conversation with an expert with a major austrian pipeline operator, which took place around 2013-12-10:

  • my request has not been ignored, it still circulates through the hierarchies of the company and is thouroughly discussed.
  • the main problem: just connecting dots (markers) results in a difference of up to 40 meters between the actual location of the underground pipeline and where OSM thinks it is.
  • this may actually be dangerous if someone relies on the OSM map when digging into to ground, hitting a pipeline where none is supposed to be according to OSM.

preliminary, we see the following options:

  • the company contributes accurate data on pipeline locations, eventually resulting in an accurate OSM map
  • a disclaimer/terms of use on the OSM proposal / pipeline plan website, rejecting all responsibility and urging the user to contact the pipeline operator in case of construction works (this disclaimer has to be presented anyway)
  • removing all underground pipeline ways from the OSM database, leaving just objects which are visible on the surface (markers, buildings, pipelines overground). this would quite hurt me.

after all, high pressure natural gas pipelines are more dangerous than telephone booths.

  • in countries like the netherlands, there is legislation requiring pipeline operators to list their pipelines in a public directory. if this trend continues, luck is on our side.
  • even if we have to remove the pipelines from the OSM database, there is always the possibility that - at any time - some other OSM user, maybe from a very different country, reconnects the dots (markers) again.
  • this means that, eventually, accurate data provided by the operators, is the best solution.

I'll get a written statement after all decisions are made, but since there's a lot of work to do before the end of the year, I'd better not expect it before the turn of the year (2013). --Rfuegen (talk) 01:09, 2 June 2014 (UTC)

Is this really that big a concern? When digging, there are lots of things you can hit - power lines, communication cables, water & sewer pipes, etc. I know in some countries you are legally required to consult official maps before you even start to dig. Even if the OSM data is accurate for pipelines, someone could still hit plenty of other things. At least from my perspective, if I saw that there was a pipeline within 40 meters of where I planned to dig, this would set off warning flags that I'd better check the official maps. --ChrisDavis (talk) 19:20, 2 June 2014 (UTC)

Sorry Chris, I missed your comment until now. From the perspective of the guy I talked to, hitting a pipeline is (understandably) a big concern, and I tend to agree with him. Legislation is different from country to country, therefore we shouldn't rely on that. And regarding human sense (check before digging) - we should always consider the worst case ;-) What we need to avoid is to give the impression of accuracy where there actually is none (or little). --Rfuegen (talk) 18:46, 10 August 2014 (UTC)

status update/2

the (written) statement promised for early 2014 never came. over winter, my interest and resources shifted to a different (software development) project. I often asked myself either to urge them for the promised statement or just keep continuing without them. since it (initially) took quite some effort to even get to the phone call, I'm rather inclined towards the latter.

ps: A 2nd major operator, contacted at the same time, (also) never replied. --Rfuegen (talk) 01:09, 2 June 2014 (UTC)

Power substations model and pipeline facilities

It's a very good point to design a tagging model for pipelines substation facilities.
Shouldn't we use pipeline=substation and add extra values to substation=* instead of pipeline=facility?
It would be consistent with early adopted tagging model on electrical power substations : Substation refinement. Fanfouer (talk) 13:08, 7 November 2013 (UTC)

good point. basically, the terms "substation" and "facility" mean the same in this context. since "substation" is already (will be) in use as power=substation, I agree to use it also as pipeline=substation. there's just one issue: some facilities (plants) like the Gas-Kompressorstation at Auersthal/Austria [1] are quite large and therefore not really a substation. maybe tag plants of this size as pipeline=station? rfuegen 23:56, 7 November 2013 (UTC)
As far as I know, we have actually deprecated power=station in favor of power=substation for all power facilities. substation=* is here to give an idea about the utility of the substation (which can be big or very small). You should think of the proper values to use with this tag.
power=station has been misused for years since some mappers used it for power plants and other for substations. I think only one tag is the best solution.
If proposal is accepted, a dedicated page for substation=* will have to be created to not only give electrical values but pipeline ones too. Fanfouer (talk) 16:43, 8 November 2013 (UTC)
proposal updated in this regard.--Rfuegen (talk) 00:49, 9 November 2013 (UTC)
Unless Im not understanding this properly, there seems to be an issue that the tag substation=distribution is being used for both power=* and pipeline=*.--Martin2014 (talk) 14:16, 17 August 2014 (UTC)
yes, sorry, I missed this comment. On the one hand, there will be missinterpretation by software which does not consider the pipeline=substation tag (i.e. rendering pipeline distribution as electrical distribution). on the other hand, if distribution takes place, it should be called 'distribution', be it electricity or pipelines. Since software needs to keep up with the ever expanding OSM tagset, I vote for keeping substation=distribution. and for the sake of consistency. --Rfuegen (talk) 19:06, 12 November 2014 (UTC)

Pipeline start and end places

Can't we have this information (names of the places) with geographical information processing ?
Since ways are oriented in OSM, the pipeline start and end extremities are known without tagging them, isn't it ? Fanfouer (talk) 13:08, 7 November 2013 (UTC)

the intention of these tags is
  • to enable the renderer to not only label the way with the name, but also with the origin/destination, which may be handy at more detailed zoom levels of an (i.e.) 400km pipeline
  • both places could be included in name=* of the pipeline (as they usually are on power lines), but since the three common items (name=West 4 E1-VL, ref=4W 02000, place:origin=Auersthal and place:destination=Amstetten) are different, I'd like to keep them separate and not combine them all in name=* or ref=*
  • with common rendering rules (i.e. Maperitive), it's not really possible to determine both places via geographical information processing.
  • in some cases, the "logical" origin/destination of a pipeline may be different from the "geographical" origin/destination
Example: http://www.openstreetmap.org/way/244986769 runs between two well sites within the same municipality.
  • you are right with the orientation. proposal now updated in this regard.
I know that we don't tag for the render. place:origin=* and place:destination=* are just "nice to have". no hard feelings if they are voted out. rfuegen 00:23, 8 November 2013 (UTC)
Ok I agree with this and with proposal update. Thank you for giving details.
Users could be warned about path inversion in JOSM, like waterway=*s features. Fanfouer (talk) 16:43, 8 November 2013 (UTC)

Update: some (gas)pipelines can be operated in both directions, i.e. some segments of WAG I/WAG II may form a "loop". see also current news about natural gas situation in the ukraine (may also flow from EU to UA). need to think about a tagging scheme. --Rfuegen (talk) 00:19, 4 April 2014 (UTC)

Markers with distance

There's ref of the line and a number for "milestone" distance from the end of that pipeline on every marker of large diameter gas pipeline. It would be nice to have a tag for that.

not exactly sure what you mean - if you mean the position reference on the marker, there is already a tag for that purpose: position=* on pipeline=marker. the current description isn't detailed, I'll document position=* in this proposal in better detail.

rfuegen 02:23, 8 November 2013 (UTC)

PODS Compatibility

It actually exists an open data model for data exchange about pipelines and connex infrastructure : PODS.
http://www.pods.org
I'm not so knowledgeable about it but it would be great to build the proposal to be consistent with it. Maybe some wiki contributors will would like to help us. Fanfouer (talk) 13:58, 9 November 2013 (UTC)

wow, thanks for this link. the ER diagram is pretty interesting. the main challenge is to find the major modules which are of interest for us ("location", for example). btw, the OMV Group (my country's major pipeline operator) is a member of the consortium. --Rfuegen (talk) 22:21, 9 November 2013 (UTC)

Liste

Ich hatte einmal eine Liste https://wiki.openstreetmap.org/w/images/6/69/ERDGAS.pdf erstellt. Es sollten auf alle Fälle die Schiebergruppen und Ausblasschieber mit aufgenommen werden. Das umsetzen von man_made (marker, valve, ...) zu pipeline würde ich befürworten. Am WE werde ich noch einmal genauer schauen. --Geri-oc (talk) 09:05, 12 November 2013 (UTC)

EDIT Auf alle Fälle sollte type=* nicht nur als gas bezeichnen - sonst fangen wir wieder mit Untertaggs an. (Vergleiche: http://wiki.openstreetmap.org/wiki/Key:fuel) --Geri-oc (talk) 09:32, 12 November 2013 (UTC)
Beispiel Schiebergruppe: http://wiki.openstreetmap.org/wiki/File:Erdgas_Schieberfeld.JPG -> http://www.openstreetmap.org/?mlat=50.86108&mlon=13.65945#map=19/50.86108/13.65945&layers=N oder http://www.openstreetmap.org/#map=17/50.90222/13.67938&layers=N
In English please ? Fanfouer (talk) 17:23, 13 November 2013 (UTC)
I have also read English - this can only http://translate.google.de/:
I had once created a list https://wiki.openstreetmap.org/w/images/6/69/ERDGAS.pdf. It should be included in any case the slide groups and Ausblasschieber. The implementation of man_made (marker, valve, ...) to pipeline I would advocate. I will look more closely at the weekend again. - Geri-oc ( talk) 09:05, 12 November 2013 (UTC)
EDIT: In all cases, type = * should not only refer to as gas - otherwise we start again with Untertaggs. (Compare: http://wiki.openstreetmap.org/wiki/Key:fuel) - Geri-oc ( talk) 09: 32, November 12 2013 (UTC)
Example :: Group slide: http://wiki.openstreetmap.org/wiki/File:Erdgas_Schieberfeld.JPG -> http://www.openstreetmap.org/?mlat=50.86108&mlon=13.65945 # map & layout = 19/50.86108/13.65945 = N or http://www.openstreetmap.org/ # map = 17/50.90222/13.67938 & layout = N
--Geri-oc (talk) 18:30, 13 November 2013 (UTC)

geri-oc, the PDF file is how I came to know you ;-) I agree with you, proposal has been updated, although a bit crude in some places - feel free to help out.

  • we are a bit natural-gas centered here; has anyone examples for substations for other media (water, oil, ...) which are not applicable with natural gas?
  • geri, could you provide an example picture for an Ausblasschieber?
  • I used a bing sat image as example for substation=compression. does anyone know if this is permitted by bing&osm licenses?

(in german) geri-oc, habe deine vorschläge eingearbeitet, wenn auch noch sehr krude. hast du ein beispielbild für einen Ausblasschieber? wir sind hier sehr gas-zentriert, hat jemand ideen für substations anderer pipelines (wasser, öl, ...)? das substation=compression beispiel verwendet ein bing sat bild, ist das von der lizenz her OK?

image Tag|substation|compression - I would not use - BING is allowed only as a background in editors. --Geri-oc (talk) 08:09, 18 November 2013 (UTC)
de: ist für ein ausblasventil/ausblaschieber wirklich eine eigene substation notwendig oder ist das lediglich ein ventil auf der leitung, sprich besser als node auf dem pipeline-way getaggt?
en: is a substation really necessary for a blowout valve or is it sufficient to tag it as a node on the pipeline's way? --Rfuegen (talk) 00:58, 19 November 2013 (UTC)
de: NEIN - aber es ist auch für Schieber nicht richtig (Schiebergruppe?) - Ich habe hier einmal ein paar Bilder (sind unter COMMONS frei verfügbar) eingebunden, wie ich es in Obercarsdorf gemacht habe. Pipeline und nodes im Editor ansehen.
en: NO - but it is also not right for slide (slide group?) - I N here once a some pictures (COMMONS are freely available) involved, as I have done it in Obercarsdorf. See Pipeline and nodes in the editor. --Geri-oc (talk) 09:38, 19 November 2013 (UTC)

update

added scheme for valve and measuring tagging, common types and some minor updates.

link to HinweisschilderRohrleitungen, in german, please help translating.--Rfuegen (talk) 00:34, 25 November 2013 (UTC)

Transport types

Often one can not specify diameter or pressure of the given pipeline, but can distinguish transport and distribution pipelines[2]. (this is true for different pipeline types such as gas, water or heat) This data will be pretty helpful for setting thickness of pipeline in different renders. Also such pipeline types often marked in official documents, so it's make sense to add this data. Therefore proposal is as follows: to add additional special tag through which you can specify pipeline transport function, for example something like transport_type=gathering/transportation/distribution.

pipelines operated by EVN are mostly tagged as follows (as shown on markers):
  • ND - Niederdruck - low pressure - municipal network
  • MD - Mitteldruck - medium pressure - connections between HD and ND networks
  • HD/HL - Hochdruck Leitung - high pressure - (inter)national backbone pipelines
Originally, I intended to specify HD/MD/ND (or HP/MP/LP) in the pressure=* tag, but this may cause problems with, i.e., maperitive, where only numerical values can be compared. your proposal sounds reasonable; what do the others here think about it? --Rfuegen (talk) 00:39, 4 April 2014 (UTC)
For example in Russia (and probably in some of the post-Soviet countries) gas pipelines classified as follows:
  • Major (transportation) pipelines - divided into two classes: first category (2,5-10,0 MPA) and second category (1,2-2,5 MPa) [3]
  • Distribution pipelines - divided by pressure: [4]
    • High pressure, natural gas (category I-a) - >1,2 MPa
    • High pressure (category I) - liquefied gas 0,6-1,6 MPa and natural gas 0,6-1,2 MPa
    • High pressure (category II) - 0,3-0,6 MPa
    • Medium pressure (category III) - 0,005-0,3 MPa
    • Low pressure (category IV) - <0,005 MPa
So classification only by HP/MP/LP does not cover this particular system. I don't know that the best way to describe pipeline classification for OSM, but hope this information will be helpful.

I consider this tag useful, but I'd like to name it "network": network=gathering/transmission/distribution --Rfuegen (talk) 19:13, 7 June 2014 (UTC)

Here are some links to information and diagrams that describe "Gathering" and "Transmission" pipeline networks. They both seem to refer to Transportation as "Transmission" pipelines.
http://www.eia.gov/pub/oil_gas/natural_gas/analysis_publications/ngpipeline/process.html
http://www.eia.gov/pub/oil_gas/natural_gas/analysis_publications/ngpipeline/transsys_design.html
http://petrowiki.org/Pipelines
http://petrowiki.org/Piping_and_pipeline_systems
--Martin2014 (talk) 22:34, 7 June 2014 (UTC)
that's quite a site ;-) in my experience, there are only two options to find out properties of pipelines (like pressure, diameter, content, ...)
* from pipeline markers and signs located on site
* ask the operator or an expert
I doubt that some properties can be derived from a sat image; in this case, I agree with your proposal below (basic/advanced tags). Not sure about sat images for the description of (municipal) distribution networks which usually run underground, covered by streets (asphalt/tarmac). --Rfuegen (talk) 22:05, 23 June 2014 (UTC)
There are a few good data sources Im aware of for details on the main O&G pipeline network:
  • Ive just removed quite a few of these data sources as it turns out they mostly had licences that are incompatible with OSM, and shouldn't be present on the wiki.--Martin2014 (talk) 20:19, 7 August 2014 (UTC)
Your'e right "satellite imagery" was the wrong phrase to use. I meant more that by looking at the layout of the pipelines one has drawn, and with some knowledge of what function the industrial complexes that they lead to and from have, it might be possible to fill in the network=* value. The kind of mapping your'e doing in built up areas is much more challenging than just tracing in the main O&G transmission network, which in places such as Russia or in the desert are as clearly visible as a motorway. I agree the municipal distribution network is impossible to map from satellite compared to these.--Martin2014 (talk) 19:45, 24 June 2014 (UTC)

Going by the information in this booklet (pg 59) the O&G Gathering network consists of:

  • "flowlines" which go from the well to one of the Field Gathering Stations (FGS)
  • "trunk lines" which go from the FGS to the field's Central Processing Facility (CPF).
The FGS an the CPF are easy to spot if one can make out the tracks of the pipelines.

From tracing the transmission network from Bing I think this could be divided into

  • branch lines that go from the field's CPF and join onto the main network, usually at a pumping/compressor station. These tend to be narrower than the pipelines in the main network and usually just one pipe.
  • the main network.

Possible tagging: network=gathering/gathering_trunk/transmission_branch/transmission/distribution

If these values were included into the network tag scheme then one could make quite a clear line-width graded map of the transport and gathering network. I don't know much about the distribution system so Ill leave that to someone else.--Martin2014 (talk) 13:16, 13 July 2014 (UTC)

Martin2014, thanks for your research and input. this "Oil+and+gas+production+handbook" you found is a great source, I need some time to go over it. what do you think about collecting all the links you found in a structured form on a separate wiki page?
I'm adding the FGS/CPS facilities to the substation section of the proposal, I'm also adding network=* to the proposal. please feel free to edit these items on the proposal if you feel that the wording needs to be changed/clarified. maybe you could provide some screenshots for the Examples section? feel free to add them yourself if you like them, I'll look over them afterwards. --Rfuegen (talk) 00:33, 1 August 2014 (UTC)
No problem, thanks. Ive put together a Pipeline_data_sources page, (please everyone add to it with whatever you find) and I'll start taking some screen shots as I go.
Ive added a few values to the network key. Ive come across quite a few references to "export" pipelines which run from the field CPF to the main transmission network though I cant find a proper definition anywhere. [5] [6] [7] [8]. transmission_branch might be clearer though as "export pipeline" is sometimes used to refer to the cross-border transmission network. --Martin2014 (talk) 18:06, 3 August 2014 (UTC)
After reading the first pages of the ABB document, I added a substation=processing to the proposal. I wonder if this also includes substation=central_processing or if we should keep these two tags separated? --Rfuegen (talk) 19:36, 10 August 2014 (UTC)
Im looking on page 16, which I think is what you were. I think this is talking about massive 'Natural Gas Processing Plants' http://en.wikipedia.org/wiki/Natural_gas_processing (aka Gas Plant, Gas Refinery which both redirect to the same page on wikipedia) If we start labeling these as pipeline substations then we would also be including oil refineries (type=oil) as pipeline substations which is perhaps stretching the definition of a pipeline substation. There isn't a cohesive tagging system for refineries in OSM yet, but ive included one in the industrial=* proposal talk page. It needs expanding to include more attributes and so on, but let me know what you think of the basic idea.--Martin2014 (talk) 14:16, 17 August 2014 (UTC)
Yes, I see the point here. the main purpose of pipelines is to transport the medium to the processing plants, but not the processing of the medium. I agree to remove the processing tags from the proposal. --Rfuegen (talk) 23:22, 8 October 2014 (UTC)

Pipeline Diameters

  • pipeline diameters are currently being entered in both millimetres and inches, sometimes with the unit present (110mm), and sometimes without it (14). Also sometimes both interior and exterior diameters are being entered (93.8/110)
This mixture is not machine readable, so will not enable a map to be made that renders large pipelines differently from small ones.
The unit mm have already been suggested as part of the PipelineExtension and I suggest including the unit in the key to make things clear. For example: diameter_mm=110
And maybe an additional tag diameter_interior_mm=93.8 for anyone who wants to get detailed.--Martin2014 (talk) 14:59, 11 May 2014 (UTC)
I have not any clue of pipelines, I hope my comment still helps: Such a tag name seems not to be conforming with the common tag conventions. See Any_tags_you_like#Syntactic_conventions_for_new_tags (":" is more common nowadays). However: usually metric units are the default. See Units. If someone means inches he should tag it in the value(!) as in tags like "width". --Aseerel4c26 (talk) 22:27, 1 June 2014 (UTC)
Thanks for bringing that to my attention. My problem is that I don’t know how to get TileMill to read this diameter data (12in, 40", DN400, DN 900, 53/63, 650mm etc) as numerical for creating rendering rules - do you know if there is a way? This may just be my lack of computer knowledge. I’m only learning as I go.
On reflection, my idea of introducing a new diameter:mm=* tag might not be the answer as it may well just complicate things further and lead to the pipeline diameter data being spread over several keys as people are used to using tags like diameter=* without any units in the key and so would probably carry on doing so much of the time.--Martin2014 (talk) 00:19, 2 June 2014 (UTC)
Offtopic: No, sorry, I never did any rendering myself. I also never used TileMill. If you have a question regarding tilemill (in fact you have a question regarding CartoCSS, if I understand correctly) go ahead and search for help e.g. in the forum or in our help page. Please search in the old questions/threads before posting. --Aseerel4c26 (talk) 22:06, 2 June 2014 (UTC)
I'm not sure if there's a way to do this aside from creating rendering rules for groups of tags that indicate roughly the same diameter. The documentation on TileMill selectors shows how to filter different tags, but it's a bit basic. Standardizing the measurement tags in some way would indeed help quite a bit. --ChrisDavis (talk) 22:53, 2 June 2014 (UTC)
I think the transport_type=* <gathering | transportation | distribution> tag suggestion above is much more likely to yield data that can be easily be turned into a map. Also, the transport type can be deduced from studying satellite imagery, so could be reliably entered worldwide. Perhaps the man_made=pipeline optional tags should be grouped into two sections: "basic" (i.e. the tags we need to make a basic world map) and "advanced" (more detailed data which can be entered if data is available), and include a suggestion that people should fill in all the basic tags whenever possible. Once the dataset gets sufficiently mature, we would start being able to use the advanced data for making a more detailed map.
To my mind the "basic" tags are:
man_made=pipeline
type=*
transport_type=*
location=*
--Martin2014 (talk) 12:38, 3 June 2014 (UTC)
agreed. I don't think it is necessary to include this in the proposal, since it is (should be) common sense to only add tags/properties which are known. --Rfuegen (talk) 22:08, 23 June 2014 (UTC)
first, the nominal diameter should be specified, which is usually defined in industry standards. since (in german) "DN" stands for nominal diameter, it is (with this definition of diameter=*) not necessary to include it in the tag's value.
second, since there seems to be no solution which is a) machine readable and conforming to the Any_tags_you_like#Syntactic_conventions_for_new_tags conventions and convenient to the user, I'd prefer to
a) stick to the proposal's definition of millimeters (nominal diameter)
b) also tolerate inches followed by ", i.e. 40". acceptance of unit millimeters may be low in countries where the imperial system is still used; conversion from inches to millimeters could be done automatically (multiply by 25.4, but do we get the nominal diameter in this case?); maybe even renderers can some day process rules like "if value ends with '"', then ..."--Rfuegen (talk) 19:21, 10 August 2014 (UTC)
Your ideas all sound fine to me. I was a bit surprised that something like mapbox couldn't do that as it seems like a fairly basic function for rendering data. Another option would be for someone who is good with computers to send a bot through the data and transform it all into mm, so then any renderer could deal with it.--Martin2014 (talk) 14:16, 17 August 2014 (UTC)

Seamarks

check out the pipelines/ways within this restricted area: http://www.openstreetmap.org/way/220138729 interesting tagging scheme, obviously originating in seamark tagging --Rfuegen (talk) 21:02, 10 August 2014 (UTC)

Documentation for the seamark pipeline tagging scheme can be found here: https://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects It apparently doesnt have its own wiki page yet.
I read somewhere on the wiki a while back (cant remember where) that OpenSeaMap tagging schemes should be used in tandem with OpenStreetMap tagging schemes rather than instead of them, which is how this has been tagged. The taginfo stats for the O&G ones are here: https://wiki.openstreetmap.org/wiki/WikiProject_Oil_and_Gas_Infrastructure#Pipeline_tags --Martin2014 (talk) 21:33, 10 August 2014 (UTC)
Though submarine=yes has been used rather than location=underwater which I havn't seen before--Martin2014 (talk) 21:49, 10 August 2014 (UTC)
hm. haven't thought this thru in detail yet. as a first shot:
a) we keep to our schema, the transition between the two schemes happens where the pipeline enters/comes out of the water.
b) we could make some adaptions, i.e. change type=* to product=* and incorporate CATPIP into our network=* scheme. the seamark scheme doesn't seem to distinguish between gathering, (long distance) transport, distribution networks, it just knows 'supply'. whereas, I'm not happy with submarine=yes, because it could (i.e.) be used in combination with underground=yes, causing ambiguity.
I'd rather stick to a). --Rfuegen (talk) 00:06, 9 October 2014 (UTC)
Please document to this proposal that subsea pipelines are to be marked with seamark:type=pipeline_submarine and belonging atributes. Even though OpenSeaMap taging scheme is to be used in tandem to the existing OpenStreetMap tagging, there is no reason to create two different tagging schemes when revising a system. The original reason behind the OpenSeaMap tandem tagging was due to the way it harvested data for its rendering, with the new renderer it is no longer necessary though the tagging scheme sticks due to the total number of object tagged this way, the information complexity in many objects, and to have a uniform tagging scheme. --Skippern (talk) 14:47, 14 November 2014 (UTC)

Oil & gas pipeline capacity

It would be good to include the capacity=* of oil & gas pipelines. The unit that seems to get used is barrels per day.

a capacity=* tag is a good idea. if we do that, the value should be free text. the capacity may be measured in barrels per day (oil), m³ per hour or day (gas), liters per second (water), etc. I doubt that we can find a machine readable representation that is easy to determine and calculate for the mapper.--Rfuegen (talk) 18:55, 10 August 2014 (UTC)

Pigging stations

Pigs are not only used for inspection. In oil pipelines, pigs might be used for just separating different qualities of oil. So instead of inspection this should be named pigging. Basstoelpel (talk) 21:05, 20 June 2014 (UTC)

there have been concerns that the expression "Pig" may be considered "offensive"/inappropriate in some countries/cultures, therefore the decision was made to use inspection_gauge=*. also, to users unfamiliar with pipeline technology, "Pig" (Pigging) may be misleading, whereas the term "inspection_gauge" makes more sense. and, nonetheless: the "i" in "Pig" stands for inspection, therefore it doesn't make a difference of the purpose if the term is abbreviated or not. hth. --Rfuegen (talk) 20:58, 23 June 2014 (UTC)
It is PIG, not Pig, and it is originally an abreviation for Pipeline Inspection Gauge or something in that direction, but have become an industry term. --Skippern (talk) 15:59, 14 November 2014 (UTC)

Large number of type=* values

We currently have over 130 pipeline type=* values in the OSM data. There's nothing wrong with being specific, but a lot of these values are duplicates of each other. Ive included the list below and will try to find time to go through it, organise it into groups and highlight all the ones that we could include in a suggested type=* value list, to try and stop number of values ballooning any further.--Martin2014 (talk) 14:16, 17 August 2014 (UTC)

let me help you with that. --Rfuegen (talk) 21:22, 9 October 2014 (UTC)

type=gas

gas
Gas
gas (empty)
natural gas
natural_gas
gaz

type=cng

cng

type=lng

lng
LNG

type=butane

butane

type=propane

propane

type=methane

methane

type=propylene

propylene

type=ethylene

Ethylen
ethylene

type=oil

oil
Oil
petroleum

type=fuel

(raw fuel)
fuel
fuels
gasoline;jet fuel;diesel
kerosene

type=hydrocarbons (a generic tag that can be used if you dont know the exact substance in the pipe.)

hydrocarbons
hydrocarbon

type=water

water
Water
irrigation
hydroelectric
hydro
head (means the gravitational drop at a hydro power plant)
drawdown http://en.wikipedia.org/wiki/Drawdown_(hydrology)
waterway
condensation_water
saline water
saline water;water
salt_water
salted water
brine
water;hot_water
hot_water;water

type=heat

Fernwärme
heat
heat;heatwater
heat_water
heating
heatwater
hot_water
hot_water;heat
steam

type=sewage

Kanalizacja
waste_water
wastewater
wate or sewage
drain
sever (mis-spelling of sewer?)

type=slurry

slurry

type=chemicals (a generic tag that can be used if you dont know the exact substance in the pipe.)

chemical
chemicals

type=ammonia

ammonia

type=caustic_soda

caustic soda

type=cvm

gaz chlorure de vinyle (CVM)

type=sulphur

sulphur

type=carbon_monoxide

carbon monoxide
CO

type=liquid_hydrogen

LH2 (means liquid hydrogen)
hydrogen

type=liquid_nitrogen

liquid nitrogen
nitrogen

type=liquid_oxygen

LOX (means liquid oxygen)
oxygen
oxygen;nitrogen

type=blast_furnace_gas

Gichtgas (EN: Blast furnace gas)
furnace

smoke/exhaust

smoke
exhaust

cable ducts

cable
cables
electric
electrical
electricity
power;cables
telecom

construction/industrial solids

beton (german for "concrete")
cement
gravel
gypsum
sand
ironsand
coal
ash

food related

beer
Fish
flour


erroneous (not to be used as type=*

high frequency
abandoned
disused
empty
FIXME
watershed
underground
overground
pressure_reduction_station
unknow
unknown (this is implied already if no value is entered)
suspected_gas
suspected_heat
suspected_water (much better to use type=water and add a note=* , otherwise every single type=* "value" could end up with a "suspected_value" version.)

to discuss

any substance
any_substance (I think all pipelines are specialised in some way. Perhaps this was just the editors way of saying they dont know.)
conveyorbelt (is a conveyor belt a pipeline?)
animals - used for tunnels giving passage to animals underneath railways. already tagged as tunnel
mixedpipeline tunnel

unsorted/unchecked

Kohle
cold
steam / chemicals
neutron pipe (particle accelerator pipeline?)
nuclear_waste (!!!!?)
rurociag flotacyjny

Thnx for your work, I included the highlighted ones on the proposal page. I'd like to move the proposal on to the next stage - Proposal#Proposed --Rfuegen (talk) 23:06, 31 October 2014 (UTC)

Good plan. Ill try and find the time to finish off the man_made=petroleum_well, industrial=hydrocarbon_field and industrial=refinery proposals so that what is at the ends of the pipelines has a decent tagging system too. I've already done most of the hard work for those three.
I posted a possible issue a while back at the end the 'Power substations model and pipeline facilities' section above. It might not be a problem at all, but I'm not sure you noticed the comment as I did several other edits at the same time.--Martin2014 (talk) 09:38, 8 November 2014 (UTC)
I don´t think type=* is a good tag to use if this tagging scheme should be compatible for use in relations. You are not able to tag a relation with for example man_made=pipeline + type=route (it is a route relation) + type=gas (it is a gas pipeline), I suggest rather to use product=* or similar, to avoid conflicts in relations. --Skippern (talk) 16:59, 14 November 2014 (UTC)
you are right on that; this issue also came up on the "tagging" mailing list and it will be changed. not happy with "product" (think of sewage ...), but rather with "medium" or "medium_type". --Rfuegen (talk) 17:33, 14 November 2014 (UTC)
I have also seen content=* and similar being suggested, but content sound static to me, more suitable to man_made=silo and man_made=storage_tank. IMO the tag should be selfdescriptive and logical. efluent can work with sewer but becomes difficult with slurry and gases, medium might be a little obscure. --Skippern (talk) 17:57, 14 November 2014 (UTC)
there are some other tags in use for gas&oil infrastructure which make use of type=*, i.e. man_made=pumping_rig. in the long term, for the sake of consistency, they should also be changed. agreeing with the concerns you mentioned above, "medium" is IMHO the best solution, but sounds a bit strange in combination with well sites. --Rfuegen (talk) 23:25, 14 November 2014 (UTC)

Overhead pipelines

Sometimes pipelines have overhead spans when crossing rivers, valleys, canals, small sounds, etc. This should be tagged differently than an overground pipeline. Often the freespan of an overhead pipeline are marked with reflective and radar-reflective markers and might have special symbols on nautical and aeronautical maps denoting the danger, safe height etc. Where the overhead pipeline might affect commercial shipping (crossing a navigational canal or river), consider the use of seamark:type=pipeline_overhead --Skippern (talk) 15:00, 14 November 2014 (UTC)

good point, alread added to the proposal. I will add a more detailed description tomorrow, together with maxheight=*. can you think of any other tags that may be useful in combination with location=overhead? --Rfuegen (talk) 23:02, 14 November 2014 (UTC)
In OpenSeaMap, seamark:type=pipeline_overhead also take the category seamark:pipeline_overhead:category=* (list of values), but also seamark:pipeline_overhead:reflectivity=conspicuous/not_conspicuous/reflector (radar reflectivity) and seamark:pipeline_overhead:conspicuity=conspicuous/not_conspicuous (visible conspicuous)
I am sure that there might be tags of aeronautic interest, but have no knowledge of such tagging scheme, some aeronautic tags might be duplicates of seamark tags. --Skippern (talk) 10:36, 15 November 2014 (UTC)

Create a relation

Some information would better fit into a relation, like the "network" or "place:origin" or "place:destination" where the place could be a member of the relation with a role "origin"/"destination" (similar to a route relation).-- Pieren (talk) 15:24, 14 November 2014 (UTC)

Actually I think that should follow the same (or similar) model as relations of route=power --Skippern (talk) 15:57, 14 November 2014 (UTC)

The use of a relation for pipelines is already in the back of my mind, but I want to propose this later in a separate proposal. the rationale: long distance pipelines (at least here in austria) are divided into shorter segments, usually with a substation=compression between them. these segments have different names & refs, i.e. "FL West 4 Sektion 1", "FL West 4 Sektion 2" etc. the future goal is to combine these segments (ways) into a single relation representing the whole pipeline. this leaves two questions:

  • logically, a segment also does have a place of origin and destination ("hey, I finally mapped the whole segment from Enzersfeld to Sierndorf!")
  • this would require to create a relation even for short pipelines, i.e. running between two well sites (i.e. "Höflein 1" to "Höflein 5")

but I don't see a reason why we can't have origin/destination information on both the pipeline way and future relation.

the "origin" and "destination" places are only for long distance pipes. The risk to have the same information on many elements is inconsistency. We also avoid duplicates (it's like the 'ref' on roads) --Pieren (talk) 17:04, 14 November 2014 (UTC)
I think "network" should be tagged to the way not the relation:-
On a transmission pipeline, the pipelines connecting the main line to each compressor station are still part of that particular transmission pipeline project, so should probably feature in a relation. But it seems right to give them a separate network tag network=facility as they are not part of the main transmission line, and this also provides a way for the renderer to differentiate between them and the main pipeline as they only need to be rendered at higher zooms.
Also, if an oil or gas field's pipeline network were to be put into a relation (is that the plan?), it would contain network=flowline, gathering, injection(possibly), flare_header, facility and export. --Martin2014 (talk) 23:35, 16 November 2014 (UTC)

How about namespace?

There is really useful thing for making keys more uniform and readable: using the namespace. Such as: pipeline:network=* pipeline:origin=* pipeline:destination=* Keys like "place:origin" or "place:destination" are, technically, misuse of namespace. Main purpose of namespace is to isolate tags within a single area of usage. --BushmanK (talk) 22:02, 12 December 2014 (UTC)

first, the primary tag man_made=pipeline IMHO pretty much defines the scope of the secondary tags; I'd therefore consider additional pipeline: prefixes rather redundant.
second, there has been no definite consensus on the tagging mailing list regarding the use of namespace prefixes for pipelines, but rather a tendency not to use them.
third, network=* is no longer in use in this proposal, since it has been replaced by usage=* during the discussion phase.
fourth, as mentioned in your vote: type=* is not proposed here, since it has also been replaced by substance=*, to not cause any troubles with relations. I'm sorry that I missed one occurance of type=* in a table header.
I don't insist on using the place: prefixes, but I'm rather hesitant to change the proposal during the voting process. --Rfuegen (talk) 15:24, 13 December 2014 (UTC)
Actually, I was not talking about "type=*" only. Did you try to look up keys you are proposing in Taginfo? For example, usage=* key: usage values. As you can see, this key is used for whatever things people want. It does not matter, when we just rendering a map from database or converting it into another format, because in this case workflow of data processing goes from geometry feature to analyzing its tags and applying rules for it accordingly. But for queries (remember, OSM is a database first) this situation adds additional level of complexity, because we have to filter out same keys used in different context. Therefore, number of query conditions grow and it causes growth of required resources amount to perform the same simple query. Pipeline tagging scheme has pretty diverse context, so queries could be really complex. In addition, it's always useful (applying some common sense, of course) to make tags a kind of self-explanatory. Namespace does a good job for it. And, you already using namespaces for some tags, so why not to extend this practice to other tags to add a grain of clarity to over-used tags (like "usage") and to avoid confusion (like in case of "place:destination", where "place" would be definitely associated with populated places instead of pipeline infrastructure). Again, I'm not insisting on changing the whole idea - idea is good and useful, but tags are controversial. Speaking of consensus regarding namespaces in mailing list - I'm not aware of that discussion, but my experience tells me, that people are rarely have deep understanding of namespace importance in multi-scheme databases, therefore part of them misusing namespaces just to make prefixes, while other part of them are scared of that misuse. --BushmanK (talk) 02:53, 14 December 2014 (UTC)

Voting

voting process for this proposal has started.

Substation examples

Excuse me, if I write too late.
I have two questions about substation examples:

  1. Why have first and last example tag area=yes? It does not make sense here.
  2. Examples are marked with landuse=industrial, but in proposal's text nothing is written about it. I think that this tag is here excess and unnecessary. Which method is right? --Edward17 (talk) 10:27, 13 December 2014 (UTC)
you are right, area=yes comes from an early draft and is not really necessary resp. redundant here; I missed to clean them out. The main intention here is to introduce the specific substation=* tags, to be combined with already established and widely used tags like landuse=*. --Rfuegen (talk) 15:31, 13 December 2014 (UTC)
Thanks for deleting area=yes. What about landuse=industrial: in Wiki-description are described plants, factories, warehouses. Subatations don't produce something, so i think that landuse=industrial is here unnesessary and even wrong. --Edward17 (talk) 11:53, 14 December 2014 (UTC)
On the landuse industrial page it says " Industrial land may include buildings like workshops, factories or warehouses and their associated infrastructure". I think substations and any other pipeline related landuse can reasonably be counted as "associated infrastructure". --Martin2014 (talk) 16:31, 14 December 2014 (UTC)
I think: pipeline substations are independent infrastructure that doesn't belong to landuse=industrial. And user Pieren wrote right at the main Proposal page: it's enougt that substation is within thу polygon landuse=industrial --Edward17 (talk) 13:28, 17 December 2014 (UTC)
Im not sure pipeline systems can be called 'independent' infrastructure. They are built to carry the product either generated by or used in a particular industrial process, and so they are a part that industry. They cant function independently of an industry.--Martin2014 (talk) 11:04, 19 December 2014 (UTC)
and what if the polygon is the substation? not all substations are buildings; in fact, there are quite many fenced areas with just some pipes and valves valves coming out of the ground, see for example Substation Example.jpg
and honestly, you vote down the whole proposal just because you don't like a single tag in the examples? --Rfuegen (talk) 20:22, 18 December 2014 (UTC)
Martin2014: I mean, mostly industry cant function independently of the pipelines. :) And what if pipeline distribute gas to dwelling houses and substation stay in courtyard?
I think I see what you are getting at - that things might go to the ridiculous extreme of tagging the kitchen sink as a landuse=industrial, pipeline=substation because there one controls the flow of the industrial product through the pipeline to the consumer... Tagging schemes can only offer a guide I guess. Each mapper has to use their own judgement and common sense somewhere along the way when interpreting a situation.--Martin2014 (talk) 15:00, 19 December 2014 (UTC)
I don't suggest use landuse=industrial on pipeline=substation. Vice versa, I think that this adding is wrong. I also don't understand, whereof is here an example about a kitchen sink. --Edward17 (talk) 17:51, 19 December 2014 (UTC)
Rfuegen: When the substation is an area, it's also enough that substation polygon (pipeline=substation) is within thу polygon landuse=industrial.
And honestly... Yes. If this tag is here wrong, it must be deleted. But if it is here right, it should be described in text of proposal. --Edward17 (talk) 13:49, 19 December 2014 (UTC)
In the case of the substation in the picture (which is in my neighbourhood), the substation is completely surrounded by fields landuse=farmland, ending directly at the fence, except for a small service track. As to your point of view, the polygon landuse=farmland has to contain a new polygon landuse=industrial, which in turn needs to contain pipeline=substation, if I understand you fully. I'm not buying that. regarding changing the proposal, see the new paragraph below coming up soon. --Rfuegen (talk) 09:14, 20 December 2014 (UTC)
Unfortunately, you understood me all wrong. I say only that substations can't have landuse=industrial tag. Newer.
Excuse me if the reason for our misunderstanding is my bad English. --Edward17 (talk) 14:01, 20 December 2014 (UTC)

In-Vote Statement

Guys,

  • The proposal has been in draft state for more than a year and in pre-vote discussion state for more than a month, being discussed here on this page and on the tagging mailing list. during these periods, many tags suggested by others have been adopted. I'm a bit puzzled that just a few days after voting has started, tenacious opposition to a few tags arises. There was plenty of time before.
  • I see some points in your arguments, and for the sake of peace, I'd be willing to adopt them, but I can't change the proposal now that it is in the voting stage (minor corrections have already caused a bold warning message in the voting section), and I won't cancel the voting process.
  • Let the majority decide. Never the less, this is what democracy is here for. If it passes and you are not satisified with the result, feel free to initiate a follow-up proposal. If this proposal fails, feel free to take it over, adapt it to your point of view, and run it again.
  • Keep in mind that we are talking about pipeline infrastructure here, which is (IMHO) of interest (and maintained by) just a small minority of OSM mappers. we are not changing the very core of OSM here!
  • a (not relevant) sidenote: I myself added more than 1600 pipeline marker, each of them visited and surveyed personally in the field (among other objects, like substations). This proposal changes some of the initial tags (i.e. mount=*) to ones suggested by others (i.e. support=*), meaning I have to change 1600 objects, and I'm happy with that, because the new tags are better suited. I don't insist on certain tags/schemes just to make my own life easier. --Rfuegen (talk) 10:24, 20 December 2014 (UTC)

Non-oil/gas examples

I know voting is underway, so this is just for information. Someone requested this elsewhere on the page.

Here are some of the real world mappable items I have seen in other types of pipelines. I think most/all can be mapped with the current proposal.

substance=water (drinkable):

  • Short gathering pipelines from wells to substations.
  • Long distance collection pipeline systems feeding from countryside/suburbs to large cities.
  • Distribution pumping stations where variations in geographical elevation or large network sizes make it impractical to feed the necessary pressure from the main waterworks processing plant.
  • Pressure reduction valves where the opposite happens, e.g. for downhill neighborhoods where the pressure on the uphill network would burst the pipes inside peoples houses downhill.
  • Actual water towers for neighborhoods that are uphill from the distribution network, these obviously include pumps, but also the buffering of a very visible elevated tank.
  • Giant overhead roman aqueducts, some disused, some ruins, some upgraded for current use (ok, I have not seen these in person).
  • Single-destination stop valves for use in case of major cases of domestic burst pipes, construction work etc. These are so rarely operated, that not mapping them exactly creates real risks that they cannot be located because the previous person to know the location is senile (and retired), and the ground markers have been covered with dirt, plants and/or asphalt (not naming names).

substance=sewage:

  • Private pumping facility that raises sewage and drainage from a deep basement to the higher elevation of the sewage "distribution" network (makes sense to map the gathering of sewage as distribution and its disposal as the collection, except for the flow direction).
  • Local pumping facility that raises sewage (drainage) from e.g. a tunnel or other extra-low point.
  • Pumping stations raising the sewage, so the pipelines don't go ridiculously deep underground (they need to slope downwards by a few percent, regardless of the landscape above).
  • Pressure pumping stations squeezing sewage into a much smaller diameter pressure pipe for transport to a remote sewage network.
  • Overflow emergency storage for use during occasional heavy rainfall. May be open top or covered, but is generally kept (mostly) empty 99% of the time.
  • Designated flooding areas for drainage in case of extreme precipitation, these generally function as recreational or nature areas under normal weather conditions.
  • Actual sewage processing plants where the sewage is cleaned and processed to the point where it can be released without destroying downstream nature.

substance=heat:

  • Actual medium may be in steam or water form depending on temperature/pressure, this may even differ for the out and return directions as well as seasonal and diurnal variations.
  • Pipeline pairs (out and return) in a single larger pipe shell with common insulation.
  • Pipe pairs (out and return) as separate pipes with independent insulation.
  • Either kind of pipe pair may lay in close parallel with another similar or identical pair for some distance.
  • Electrical damage sensing gauges inside the pipe insulation, so leaks and broken pipes can be located by electrical measurements from the pipe head/substation/main valve. These typically consist of a simple pair of copper threads in the insulation foam, hooked up continuously as pipe segments are combined into a pipeline, leaks into the insulation cause shorts, a completely severed pipe breaks the line.
  • Overground pipes crossing highways (of any size, from walking path to freeway), railways, and even waterways.
  • Distribution substations etc. like for other pipeline networks.
  • Small and large generation plants that are their own industrial buildings.
  • Large (and small) generation plants that also produce electricity in a roughly 50/50 split (this pays off due to the 2nd law of thermodynamics).
  • Large generation plants that are also solid waste (trash) incineration facilities. These may or may not also produce electricity, resulting in a triple usage utility to be tagged for all 3 kinds of purpose. Though I have not seen it, these may also be combined with sewage processing in order to extract energy from the biological part of the sewage.

Jbohmdk 06:11, 14 December 2014 (UTC)

thank you very much for this information; it may be useful for the wiki page in case this proposal goes through. --Rfuegen (talk) 17:57, 17 December 2014 (UTC)

valve type

Hello! valve=* is conflicting with the established use to specify the mechanism of the valve (globe, butterfly, ball, gate, etc). That type is actually verifiable and posted on the wall on the marker plate, unlike the kind of "valve" designation that this proposal introduces. Bkil (talk) 14:21, 24 February 2023 (UTC)

Indeed but not a problem. valve=* was refined in 2018 with Proposed_features/Pipeline_valves_proposal which gave it its current usage. Did you find something misleading referring to this 2014 proposal instead of 2018 one? Fanfouer (talk) 14:29, 24 February 2023 (UTC)
I would like to map what I can see on the ground (the mechanism of the valve). What key should I use? Bkil (talk) 15:22, 24 February 2023 (UTC)
valve=* Fanfouer (talk) 15:26, 24 February 2023 (UTC)
And how could someone else refine the purpose of the valve later on if the mechanism already occupies the key? Bkil (talk) 15:31, 24 February 2023 (UTC)
It is possible with a formal proposal providing a different key we currently don't know. Fanfouer (talk) 15:36, 24 February 2023 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:PipelineExtension&oldid=2516471"