[Talk-us-massachusetts] intro and intent

[Greg Troxel]

hobbit at techno-fandom.org writes:

[I stepped away from this discussion for a while and trying not to be
redundant.  I believe it's bad to tag for the renderer (TFTR) of course,
but for the public record I think:

  - landcover tags that are on objects also tagged with landuse is
    always wrong (because trees happen, and it should be easy to adjust
    the landcover to follow the actual area, without placing the object
    detangling burden on that person).  I think it's reasonable for
    people to remove such landcover tags when they come across them.

  - landcover tags (on separate objects) that are tightly aligned with
    landuse objects/parcels/etc. are almost always wrong, and are
    actually wrong if they fail to extend to the edge of the landcover.

  - we should maybe create a maproulette challenge to fix the above

  - MassGIS has a landcover/landuse dataset, which I have not grasped,
    but it should be easy enough to load it in qgis.
       https://www.mass.gov/info-details/massgis-data-2016-land-coverland-use

    Probably we should see about importing it, perhaps partially, due
    diligence of course.  That will negate the rendering value of
    "conservation green" (which is fine because adding actual-extent
    landcover near conservation and only conservation, while technically
    valid in each instance, is as a systematic practice more or less
    tagging for the renderer).  I think it will also point out that
    Carto's choices of rendering at smaller scales don't work well for
    us -- but maybe people from RI can comment.  This of course can be
    tested without uploading, rendering
      OSM
      - remediating the above TFTR
      + MassGIS landcover
    with Carto and looking at it.
]

> And it looks like I'm still confused by "Mapnik" vs. "Carto".  Still reading...

The standard approach in OSM to raster tiles (where there are 256x256
images, in a variety of scales, on a uniform grid spacing) is:

  - get osm data

  - import it into postgis (e.g. via osm2pgsql)

  - install 'mapnik' which is software that produces tiles from the data
    in postgis'

  - configure mapnik to use as a style "Carto", which describes how to
    render the elements in the database.

In the early days, I think the style was part of the mapnik repo, so
mapnik the rendering software and the style were sort of the same thing
but now they are clearly separate.  So you can use mapnik with some
other style.  And of course you can change mapnik or Carto yourself, but
mostly I think you will want to modify Carto, and mapnik mods are about
adding the ability to express something you can't now.  Plus the
"import" step can do transform/filter too.

An important point about Carto is that while everyone complains about
some decision they have made, there is no viable alternative style that
is maintained and widely preferred (for general use).

I think that a style for people that care about hiking and conservation
land is just going to make different choices from a style that is about
driving.

It would be a real contribution to work out a modified Carto that shows
landuse=nature_reserve with a green fill (landuse=conservation used to
have a dark green fill) that works well also with landcover, both here,
and in Europe, and to submit a PR with publicity about it on talk at .  I
suspect that until then the Carto people will say something like "this
is hard and we don't have a specific pull request with good test output
on the table, so you can't complain that we are refusing to accept it".
Whether that turns into refusal or acceptance, I can't say -- we haven't
come to the bridge.

Note that OsmAnd has multiple style variants; trails are deemphasized
while in driving mode.  Note also that you can change the OsmAnd render
style to make it do things differently, and you can submit pull
requests.  I don't have experience with how that goes, but the OsmAnd
defaults are in the same boat as Carto, having a requirement to be all
things to all people -- but the advantage of being divided into usage
modes.  A "outdoorsy" mode might be good, or perhaps "hiking" and
"woods-type mountain biking" modes.  I say two because lots of trails
have access= for hiking and not for bicycles; that's very common in my
town's conservation land (unmaintained trails are like that, by posted
rules).

So one can:

  - do the above, but with a modified version of Carto
  - submit pull requests to carto after experimenting
  - create a style that is really not like carto (Brian pointed out
    Americana)

This has been on my todo list ~forever.  I'd want to (sort of design
note to self, and happy to have Americana steal any of this!):

  - rendering landuse=conservation and boundary=protected_ares,
    distinguishing private/public versions
  - render leisure=nature_reserve different somehow
  - ensure that the landuse/landcover ends up working - particularly at
    small scales this is really hard
  - ensure that landcover tags don't win over untagged when coloring
    pixels especially at small scales.  For example  if a pixel is 1km x
    1km on the grond and landcover tags are 100mx100m natural=wood and
    that's it, that's ~0, not "100% of what's tagged".  I think this
    could be contributing to how RI looks on the map when zoomed out but
    I'm not sure.  OTOH the satellite images of NE look mostly green.
  - distinguish non-paved roads
  - rationalize footway/path somehow; the thin red lines in the woods
    don't seem right
  - rationalize road/track/path/footway so that visual weight makes
    sense as items become less substantial
  - draw trails (in conservation?  all paths) by color, using tagging
    for blazes, falling back to name=Red (which is just over the line
    into acceptability as there is a sign with a red icon).   Drop
    name=color when that happens.
  - draw maintained and not maintained trails (by landowner declaration)
    differently somehow
  - draw trails by width somehow (1.5m well trodden vs 0.5m is a big
    deal)
  - draw trails by position in the hierarchy somehow, sort of through
    trails, main trails in an area, secondary, and just-barely.  This is
    hard because there needs to be a global tagging scheme for
    hierarchy, and maybe the network tag is ok for through so it's only
    lesser, but still there is Yellowstone with long trails and 40 acre
    parcels where the "main" train is not so main comaparatively.  One
    idea, not baked, is to label trails by the max distance one might
    travel on them but often there is a well-trodden 1 km  trail and
    another that is 0.5m wide and also 1km.  This is really hard and
    needs experimentation.
  - remediate TFTR like name="Main Trail"
  - remediate TFTR of landcover that is on an object also tagged with
    landuse, and secondarily and harder that is tightly aligned with
    parcel boundaries or landuse-tagged objects
  - add in parcel boundaries, probably merging those under common
    ownership - as you have noticed there are often multiple parcels in
    conservation areas, because the state hasn't bothered to file 81x
    plans (like a citizen would have to in order to be freed of internal
    setback rules)
  - Figure out how to show or not show peaks depending on prominence.
  - show towers/antennas depending on height/prominence, or maybe just
    more than Carto does, and other things useful for people to orient
    themselves, or that are interesting to map nerds.
  - perhaps add in topo contours, but I'm not inclined to hillshade

and surely some other things.  I still look to the old (through the 80s)
USGS topo maps for inspiration.

In the glorious future, Americana might be fully usable as an
alternative to Carto for general use, and there might be a robust,
minutely up-to-date tile serving infrastructure/CDN, and normie websites
might use it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20220722/124baa27/attachment.sig>