Add bay water feature label positions

[nvkelso]

Into the water layer.

• natural=bay, e.g. a A bay, a large body of water partially enclosed by land but with a wide mouth. (Other languages).

See also:

• http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbay

[nvkelso]

Target layer: water.

[nvkelso]

Also, straight?

[nvkelso]

Load balancing to v0.8

[rmarianski]

Did you mean natural=strait? http://taginfo.openstreetmap.org/tags/natural=strait

[nvkelso]

Yep, that's the one.

Referenced on the same page, the following natural (water) features are also candidates:

• natural=fjord
• natural=bay
• natural=fishing_bank
• natural=sound

[rmarianski]

There's only 12 sounds and 4 fishing banks. Should we still include those anyway?

[nvkelso]

Skip

On Jan 27, 2016, at 14:55, Robert Marianski notifications@github.com wrote:

There's only 12 sounds and 4 fishing banks. Should we still include those anyway?

―
Reply to this email directly or view it on GitHub.

[rmarianski]

Before:

After:

[nvkelso]

@rmarianski How were we picking up the blue water area before? Was it tagged with both water and bay? If we already have a polygon for these, is there a way to only export the label position points (not the full polygon geoms)?

[zerebubuth]

@nvkelso, there's a shoreline as well as the bay polygon (rather annoyingly, they don't match up along the shore), which means we're picking up the blue water polygon from the water / coastline polygons from OpenStreetMapData, and potentially now a mostly-overlapping polygon.

I think if we only want this for labelling, then it might be better to only extract the points - otherwise we might cause a lot more work for the exterior_boundaries code, which might be mostly wasted if all we're going to do with it is draw the same blue polygon.

Do we have any of these features inland? If so, do they overlap other water polygon features such as lakes and riverbank polygons?

[nvkelso]

Good points! Let's make an assumption that the new features are only marine related (not inland waters related), and only get points back instead of full polys in tiles. Is that best done in PostGIS or in a processing step before the Mapzen coastline transform?

On Jan 29, 2016, at 07:50, Matt Amos notifications@github.com wrote:

@nvkelso, there's a shoreline as well as the bay polygon (rather annoyingly, they don't match up along the shore), which means we're picking up the blue water polygon from the water / coastline polygons from OpenStreetMapData, and potentially now a mostly-overlapping polygon.

I think if we only want this for labelling, then it might be better to only extract the points - otherwise we might cause a lot more work for the exterior_boundaries code, which might be mostly wasted if all we're going to do with it is draw the same blue polygon.

Do we have any of these features inland? If so, do they overlap other water polygon features such as lakes and riverbank polygons?

―
Reply to this email directly or view it on GitHub.

[rmarianski]

Do we have a coastline transform step? My understanding is that we just pulled in data directly from openstreetmapdata.

I'm assuming that if we just want points, we'll want to maintain the label positions of these features in a trigger.

And just making this explicit, it will mean that nobody will be able to style these polygons differently from water, because only the label will be available. AFAIK, this is the first time we would be generating only a label without the underlying feature.

[zerebubuth]

The coastline is transformed along with everything else as part of the post-processing pipeline, but we don't (currently) do anything to it in PostGIS-land.

We might want to pull the polygons into tilequeue and then run the same label point generation code that we use for other features. In addition to being consistent and perhaps less code, it means we wouldn't have to worry about triggers / migrations for label positions. (On the downside, it means pulling more geometry back from the database, something we'd have to watch.)

Re: styling, I think it would be confusing to have these in addition to the other water polygons, as they don't seem to define the shoreline... and I don't think it's rendered on OSM's default rendering (notice the spit of background land which is underneath the bay polygon but not blue). If someone tried to turn them off, they'd find that we had intercut them with the shoreline and therefore a large chunk of water was missing, rather than reverting to the shoreline shown by default on OSM. I confuse myself by trying to talk about it! 😉

[nvkelso]

Yeah, these appear to more like “intended labeling areas” than physical
features.

On Fri, Jan 29, 2016 at 9:33 AM, Matt Amos notifications@github.com wrote:

The coastline is transformed along with everything else as part of the
post-processing pipeline, but we don't (currently) do anything to it in
PostGIS-land.

We might want to pull the polygons into tilequeue and then run the same
label point generation code that we use for other features. In addition to
being consistent and perhaps less code, it means we wouldn't have to worry
about triggers / migrations for label positions. (On the downside, it means
pulling more geometry back from the database, something we'd have to watch.)

Re: styling, I think it would be confusing to have these in addition to
the other water polygons, as they don't seem to define the shoreline... and
I don't think it's rendered on OSM's default rendering (notice the spit of
background land which is underneath the bay polygon
http://www.openstreetmap.org/way/43950409#map=19/38.01397/-122.29715
but not blue). If someone tried to turn them off, they'd find that we had
intercut them with the shoreline and therefore a large chunk of water was
missing, rather than reverting to the shoreline shown by default on OSM. I
confuse myself by trying to talk about it! [image: 😉]

—
Reply to this email directly or view it on GitHub
#400 (comment)
.

[nvkelso]

LGTM