Infrastructure edits in USA such as https://www.openstreetmap.org/changeset/137533993

Hello,

Andy from the DWG here. I’m creating a topic here to discuss edits such as https://www.openstreetmap.org/changeset/137533993. We’ve had numerous complaints about edits by this mapper in the past, and again about this particular change. I believe that it would help if the person making these edits could explain their methodology, and other people could explain the things that they believe are issues.

To get the ball rolling, here are the issues that I see, speaking as someone “familiar with locating pipelines based on on-the-ground markers and imagery evidence” (albeit in the UK not the US):

This change added https://www.openstreetmap.org/way/746288835 and https://www.openstreetmap.org/way/1183494615 , and at https://www.openstreetmap.org/#map=19/32.25617/-93.28697 they’re adjacent to https://www.openstreetmap.org/way/759488497/history (which was added by someone else previously) and Way: 833942478 | OpenStreetMap (added by this mapper the day before this change).

Sometimes the alignment matches the imagery (eg. https://www.openstreetmap.org/#map=18/32.26046/-93.26773) and sometimes it does not (https://www.openstreetmap.org/#map=18/32.25973/-93.27565). Pipeline markers for https://www.openstreetmap.org/way/759488497 exist (e.g. https://www.openstreetmap.org/#map=19/32.26141/-93.26259) but I’ve not yet spotted any for the two new ways added.

I’m sure that there’s some gas infrastructure along that corridor, but I’m not sure how anyone can see from imagery that there are exactly 4 pipelines in the indicated area? Also, since the alignments don’t match imagery presumably that came from somewhere else, as did the pipeline diameter?

I’m hoping that this discussion will allow everyone to pitch in and explain why these edits are or are not OK, and if not what would need to happen to make them OK.

Best Regards,

Andy

5 Likes

I’m responsible for the edits.

The location of those edits is at the heart of the Haynesville Shale formation, where through fracking, huge amounts of natural gas are extracted, and massive amounts of infrastructure have been built for this purpose over the last 10-15 years. (‘gathering systems’, ‘takeaway capacity’) Several parallel pipelines from different operators are not uncommon (rather the rule). This just as some general context.

The line added here was/is part of the 6000-mile Southern Natural Gas system. The line also includes a looped section. (Loop line is simply a parallel pipe, to increase capacity) I started work on this system already over a year ago, and this section (between Logansport/Bear Creek compressor stations) was the final stretch of the system (and the furthest west). I added it now a few days ago as part of an effort to continue mapping pipelines in Mississippi & Louisiana.

A part of the line which I’ve added was already mapped before by someone else. Same goes for other pipelines in the area/the corridor. (However none of those has any descriptive tags other than man_made=pipeline/location=underground, also the geometries are often somewhat rough (which isn’t something bad IMO))
(I’m talking about the longer of the two ways, way 746288835)

The ways which I added have impossible overlaps with older ways (or at least one), with more rough geometries. The opening post here links to such a situation at “Sometimes the alignment matches the imagery, sometimes it does not Link
The older way which overlaps is Way 833942478, History. I removed a section, where it was easier to just trace ‘my’ way from scratch - I intended to recycle the remaining rest of this way as part of another parallel pipeline at some future point - but not without more descriptive tagging and more comprehensive geometry details (the overlap location is by far not the only point with ‘rough geometry’) Because the entire state is a massive work in progress (related to pipelines), I didn’t bother too much about such minor details (as mentioned, I was going intending to improve the geometry/tagging of the adjacent in the near future anyway)

Re: Markers
I’m unsure if this thing you’ve linked is a marker or even related to pipeline operation. Could also be a hunting stand? Or it is some kind of measure device) (Maybe, maybe, I have no clue. If you map pipelines by markers, you know probably better) Even aerial inspection markers are often hard to spot, let alone the normal posts at high/rail/waterway crossings. (Depends on the imagery, of course)

I’m not sure how anyone can see from imagery that there are exactly 4 pipelines in the indicated area? Also, since the alignments don’t match imagery presumably that came from somewhere else, as did the pipeline diameter?
There are more than 4 pipelines. According to the PHMSA public viewer 5 lines, and I’m certain that there are more gas gathering lines (needs more research). The public viewer is from the US Pipeline & Hazardrous Materials Safety Administration, a subdivision of the US Department of Transportation. The data is as such public domain. I use this as rough reference for the routes. I’m not sure what you mean by “the alignments don’t match imagery”. This little missing curve there? Well, this is all still a huge work in progress.

The diameter came from the Federal Energy Regulatory Commision’s online library. This is not some kind of Web GIS, I have to search through the 4.4 million documents to get my information. (Last time I looked it up it was at 2.5 million, apparently they scanned/made available old documents, the earliest ones being hydropower-related docs from 1921)
There are various documents which refer to the Logansport Line (which I added) as being a “14 inch line”, at various locations. For example here on Page 4/Row 5, here on Page 5/Row 3, here on Page 2. (note that I don’t know how to link to documents directly there, so I used a filehoster.)

The original ‘problem’ with this edit was that some person (?) alleged it was an import (even “clearly”, that’s… a negative cherry on the top"), and doing this edit violates the promise I gave for my last unblock. I strongly disagree with this. In my view, this was a perfectly normal edit, which just used external sources as references. I didn’t use external geodata & uploaded it, I didn’t even ‘copy’ external data - I checked it for plausibility, made sure it’s correct & added it. This happens on OSM everyday, all over the world, by hundreds of people, and is absolutely nothing which would fall under any import guidelines.
An more extreme example: Someone in the US extensively edits/edited based an external source, in every state, thousands of objects. I would say part of this also falls into the “copying” category, because the names given have sometimes very minor issues. None of this activity is documented/discussed anywhere, but no one has ever really complained. Why? Because there is no reason to.
I also have some actual imports in mind, and started working on their documentation recently, this for example.

There also seems to be issues with how I state my sources (If i’m understanding it correctly)
I was asked about them in a changeset comment, and promptly stated them with additional detail. I don’t really see much of a problem there. In the future, I will make sure to add referenced external sources as a source tag to the changeset and keep track of all sources used on my user page. However, I will have to get used to this first (& this isn’t required by any guidelines).

Greetings

2 Likes

Technically, you’re correct that there isn’t a hard-and-fast rule requiring mappers to meticulously document their sources upfront when submitting each changeset. But that’s because the average routine changeset is using established sources that are well-known to the OSM community and built into our tooling. If source=* is absent, it’s assumed to be some vague combination of imagery_used=*, survey, local_knowledge, and common_sense. If you use more exotic sources, you always have to be prepared to answer questions about them. Citing your sources upfront prevents others from assuming the worst, so please do that going forward.

It’s only natural that you’re receiving extra scrutiny, after previous incidents in which you announced and documented large-scale imports only after the fact. A little extra due diligence will go a long way in reestablishing the community’s trust in your edits.

I agree, this is unlikely to be a pipeline marker:

Most pipeline markers are practically indiscernible even in 6-inch orthoimagery. For example, one of the most prominent marker designs in the U.S., the paddle marker, is barely visible at zoom level 20, less discernible than nearby people:

In this particular case, the pipeline happens to cross a popular trail, so a ground-level view of the marker is easily accessible on Mapillary. Otherwise, aerial imagery is mostly useful for discerning a scar on the land that obviously has the pipeline running beneath, based on comparing with older imagery or cross-referencing external documents.

6 Likes

Thank you for your input!

The issue seems to be resolved. I will continue editing, if nothing more comes.

I think the specific issues are:

  1. Documenting where data comes from if it’s an external database. Another mapper needs to be able to inspect the other database to assess both data quality and license compatibility. For example: TIGER, GNIS, and MassGIS all have pages that any mapper can look at to understand where the data came from and how to assess it. If you’re pulling in something new that hasn’t been documented before, creating a page to document it would solve a lot of heartburn.
  2. If you’re pulling in data from an external source (whether tracing or outright copying the geometries over), there needs to be some mechanism of vetting to determine whether the data is of sufficient quality that we can trust it. That’s why the community consultation is important. Mappers will view external sources quite skeptically and spot check to see if it’s sane or if it’s riddled with errors. If this is the first time a particular data source has been used then you probably need people with local knowledge to help with that vetting.

To me, these are the main reasons why the Automated Edits Code of Conduct exists. Don’t search for workarounds to avoid talking to the community - talk the community. “Hey, I want to pull in data from $DATABASE, looking for feedback on whether we think this data is good enough.” If you skip that step and just start adding things, people will rightly get pissed off when they see data that doesn’t make sense in the map when you didn’t consult with anyone. I generally recommend adding links to where the discussion happened (Slack, Discourse, mailing list, etc) or to the page where a source is documented in the changeset tags or comments.

These are not roadblocks to slow you down, these are community norms that we use to assure each other that additions to the map are in our collective best interests.

3 Likes

I actually agree with all of this, those are good reasons why imports & automated edits should be discussed.
Problem is that none of my recent edits are even remotely imports or automated edits, they are not even “copying” of any data. I’m not “pulling in external data”, I’m doing normal mapping while refencing external data.

Quoting the linked Automated Edit code of conduct: “systematic edits to the database […] without consideration of each change” - I considered each change in all recent edits, and that’s the point. Not considering each change in iD-Editor is nearly impossible, actually.

An example, where I want to “pull in” external data in the future is this already above linked, work-in-progress documentation. “Community consulting” will eventually happen. (But this is not yet finished)

1 Like

@zluuzki, what I see happening here is you concluding that community consulting will “eventually” happen. Though, it actually is, right here and now. It is recognition on your part, I say, that you are not doing enough of this (community feedback). So, please go out of your way to get more “up front” community buy-in. Especially when doing “large scale” things like pipelines and major infrastructure that span entire states and larger regions. It is sensible that we do this. There is an “edge” around “entire states and regions” where even frequent (sub-, for that area) community feedback is more-or-less essential. The entire community wants and even needs such conversation / dialog. (Because things like statewide and nationwide networks of “big things we map” benefit with such dialog).

SOME of that “buy in” is receiving “positive feedback” from our community. This can be a wide spectrum, anywhere from “nothing at all” (crickets chirping) except for “nobody complained or redacted” to wide accolades and even awards from the OSM community. I don’t want to say (loudly) that what is happening here and now is “negative feedback” I would rather say “seek more positive feedback” from the OSM community (please).

It can be a fine line between “I hear nothing” (and maybe you don’t know if your contributions are well-received) and “I know exactly that my edits will be exactly what is best for our community.” The former can be “OK, green lights to proceed” though not necessarily (so, stop, look and listen). The latter smacks a bit of hubris, and that can run rather roughshod on the wider community. Reach out: perhaps you find other community (I don’t know, other “Southern US pipeline mappers”?) with whom you can strengthen the map with “building things.” I know I map like this (In greater North America on data like rail and bicycle route networks) and it works to do so. Give it a try.

1 Like

The requirements for review prior to imports and automated edits is because of the scale of problems they can and have caused in the past. There’s no general requirement to talk to people before making edits like this. They can be discussed after the fact, like we’re doing now, and that’s fine.

It sounds like the only practice not done beforehand was not documenting the source in the changeset tags. There might also be an additional issue with leaving behind old geometries when editing in an area, causing the OSM data to conflict with itself. This is best avoided.

1 Like

I’d also like to bring up in the past that zluuzki has taken massive sweeping changes to the map that violate a couple best practices for mapping.

A while back he deleted every tiger-imported power line in Mississippi, with promises that he was going to replace it over the next couple of months.

From my point of view, if you delete something like that, you should be replacing it now, not 3 months from now, assuming its valid data. Mass deletions are extremely questionable behavior… and I wonder what other stuff has been treated this way that nobody has noticed.

5 Likes