Re: [Talk-us] Reference numbers to use for hiking trail route relations

[Joseph Eisenberg]

Many of the old "pack trail" labeled features near my home-town are now
overgrown and barely usable. I would be skeptical about the utility of this
tag - mappers will need to survey the trail in person before suggesting
that it is currently suitable for horse, mules or other pack animals.

-Joseph Eisenberg

On Thu, Oct 15, 2020 at 10:02 AM stevea  wrote:

> brad  wrote
> > I think I've seen old usgs topo maps, or perhaps FS maps with trails
> labeled as pack trails.   Not quite sure what it means, probably nothing
> anymore.   Perhaps the OSM person just used the info from the old map.
>
> A "pack trail" is suitable for pack animals, such as donkeys or horses for
> carrying "in" supplies, building materials or hauling "out" garbage, ore
> waste or the like.  It is more substantial than a "single-track" trail for
> a bipedal human, but may or may not be suitable for an off-road vehicle
> like an off-road motorcycle, all-terrain-vehicle / four-runner or other
> high-clearance, two-axle vehicle.  It is a common phrase seen on maps of
> the 19th and 20th centuries, but has fallen somewhat out of favor, though
> is still seen and used.
>
> SteveA
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Joseph Eisenberg]

Settlements which are mapped with the place=* key are usually mapped as a
node, not as an area.

There are many place=city areas in the USA, but that's because the tag was
incorrectly added to many municipal boundaries when they were first
imported, years ago.

Some neighborhoods have well-defined boundaries, such as
boundary=administrative relations, and can be mapped as such.

But most neighborhoods, like towns and villages, do not have a clear place
where the named place ends. Even in big cities with well-known
neighborhoods you will hard-pressed to get two locals to agree about the
exact place where one named neighborhood ends and another starts, unless
this is legally defined by the municipality (and even then, real estate ads
and locals will often change things).

So it's best to use place=neighbourhood, like place=town and place=suburb,
on a node at the center of the place.

- Joseph Eisenberg

On Tue, Sep 22, 2020 at 6:41 PM Paul Johnson  wrote:

>
>
> On Tue, Sep 22, 2020 at 8:36 PM Mike N  wrote:
>
>> On 9/22/2020 9:26 PM, Paul Johnson wrote:
>> > The extra hamlet nodes are import remainders that haven't yet
>> been
>> > converted to landuse areas.   The general landuse zones for that
>> area
>> > have been identified, but do not exactly correspond to the named
>> > subdivisions.   As I get a chance to survey, I divide the landuse
>> into
>> > subdivisions and convert the node to a named area for the
>> subdivision.
>> >
>> >
>> > Please don't expand these as landuse, please expand them as
>> > place=neighborhood instead.  Landuse polygons should be congruent to
>> the
>> > actual land use.
>>
>> That's a good point: the subdivisions often contain one or more landuse
>> basins, clusters of trees, etc.   I've been thinking of them as one big
>> blob, but it seem correct on a more micromap level to mark them as
>> place=, and identify the smaller landuse areas (which are sometimes all
>> residential).
>>
>
> Exactly.  My rule of thumb is if you're thinking about putting a name on
> it, and it's not a shopping center, apartment complex or similar large but
> contiguous landuse, then landuse=* probably isn't what your polygon should
> be.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Unintentional improvements in OSM data influencing / improving other databases

[Joseph Eisenberg]

RE: "Many government and agency data sources are in conflict with each
other over the same information; OSM can serve to provide "resolved"
versions that are confirmed with ground observation where required."

Similar thoughts have been expressed previously in this thread.

But if we are talking about legal parcel boundaries or legal protected area
boundaries, or administrative limits, then it's not at all possible for
OpenStreetMap users to resolve these conflicts in our database alone.

What needs to happen is bringing this information back to the local
government and asking them to correct the data and provide an
authoritative, public-domain source for everyone to use.

It's no good if OpenStreetMap has a more "accurate" boundary line which
follows a physical feature like a ridgeline, if the legal definition is
different. Determining this might require lawyers getting involved.

Now certainly OpenStreetMap data, which can include features like
ridgelines, waterways, roads and paths, which are often used to determine
historic land ownership boundaries, can be useful in determining if
existing databases are accurate and precise. But unless those outside
databases are corrected, our data will be inaccurate as well, when it comes
to legal issues like boundaries.

- Joseph Eisenberg

On Wed, Sep 2, 2020 at 11:39 AM Bradley White 
wrote:

> I echo this sentiment exactly as having taken place in California and in
>> my experiences with OSM.  This is most certainly a longer-term endeavor
>> (over several, even many years), but improvements in alignments between
>> data components which have been entered into OSM from my County GIS,
>> GreenInfo.org's publishing its "CPAD" (California Protected Area Database,
>> published semi-annually, see our wiki) and other sources HAVE INDEED
>> resulted in data improvements:  OSM influences CPAD, resulting in data
>> improvements, CPAD influenced County GIS data, resulting in data
>> improvements, later versions of these (County GIS and CPAD) data influenced
>> OSM all over again, resulting in data improvements...and upward, upward and
>> upward the spiral of more accurate, better-aligning data goes:  both
>> private and public.  OSM gets the results, so do others.  Win-win.  Taking
>> OSM out of the equation by asserting "these data don't belong in OSM" stops
>> this improvement pipeline (wholly unintentional on my part, but certainly
>> noticed) in its tracks.  (Yes, some data belong in OSM, some don't).
>
>
> I'm in strong agreement here. OSM provides a unique platform to synthesize
> multiple data sources in combination with field observation to produce
> something potentially better than any of these single sources are on their
> own. Trying to produce an accurate and detailed map of the entire US
> strictly off of field observation and satellite imagery is simply
> infesible, especially in remote, unpopulated areas. Many government and
> agency data sources are in conflict with each other over the same
> information; OSM can serve to provide "resolved" versions that are
> confirmed with ground observation where required.
>
> I agree that we shouldn't be importing parcel data wholesale, as-is. But,
> if real-life accuracy is important, the fact that much of the information
> we are trying to add in OSM (protected areas, land use, access
> restrictions) is differentiated along parcel boundaries is simply
> unavoidable to me. If this information is in the public domain and
> generally corroborates what is on the ground, so long as the data is worked
> through manually to confirm accuracy, I don't see the problem with using
> parcel information as a piece of the "puzzle" in producing an accurate and
> informative map.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cooper Country State Forest in Keweenaw County, MI

[Joseph Eisenberg]

My goodness, look at that monstrosity:

https://www.openstreetmap.org/relation/1976405#map=8/46.459/-87.627

How can we claim that all of these patches of state-owned land constitute a
single OpenStreetMap feature?

-- Joseph Eisenberg

On Wed, Sep 2, 2020 at 10:27 AM Frederik Ramm  wrote:

> Hi,
>
> the DWG has been asked to remove this bit of land
>
> https://www.openstreetmap.org/way/146418027#map=13/47.3306/-88.4441
>
> from the "Cooper Country State Forest" protected area since it has been
> purchased from the state by private individuals in 2006 and "the recent
> plat books show this".
>
> I have been unable to find an online resource to corroborate this claim.
> Googling for "plat books" turned up some very pretty scans of 1800's
> surveyor records ;) Perhaps someone more knowledgeable in the US public
> records landscape can help?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Joseph Eisenberg]

The tag military=bunker is used not only for true bunkers, but for "any
kind of military installation built to withstand an attack." - quote from
https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker

- Joseph Eisenberg

On Tue, Sep 1, 2020 at 12:10 PM Bill Ricker  wrote:

>
>
> On Sun, Aug 30, 2020, 19:55 stevea  wrote:
>
>> .  And if it was historically a bunker, OSM should strive to tag this,
>> I'm not exactly sure of the right mix of military=bunker and historic=yes
>> flavors that might be absolutely correct, but something like those if not
>> exactly those.  Though historic=ruins seems correct, too, so perhaps better
>> than "yes."
>>
>
> Technically this and most of what the public refers to as military bunkers
> aren't bunkers.
>
>  Many of the larger ones are casemated Coast Artillery gun positions and
> their magazines. These are protected to a degree better than a "bunker"
> from above, but had openings to seaward to fire which had only
> splinter-proof shielding, and these were not refuges for personel, so not
> true 'bunkers', they were fighting positions.
>
> Devil's Slide was a protected Fire Control post for Coast Artillery, and
> included a radar. (One could almost classify the radar control point as a
> bunker, as it had no windows nor fire ports, but again it's not a refuge.)
>
> http://www.fortwiki.com/Devil%27s_Slide_Military_Reservation
>
> I am a member of the Coast Defense Study Group (cdsg.org) as well as OSM.
> We study and seek to preserve these structures and the memories of those
> who built and served in them. One of our members was recently authorized to
> inspect Devil's Slide Reservation and reported on its current condition
> (and history) in an illustrated article in our Coast Defense Studies
> Journal. In addition to no-access signage it is gated and fenced. Tourist
> Safety is dubiously best as most of the handrails and safety lines are gone
> or deficient.
>
> (The nice thing about touring these sites with CDSG conferences - aside
> from knowledgeable companions - is that we negotiate "Authorized Persons
> Only" access, for which we sign copious liability waivers, and we equip and
> conduct ourselves appropriately for the expected hazards: hard hats or
> better, construction boots (or sometimes wellies/waders!), gloves,
> torches/flashlights, etc.)
>
> // Bill
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest

[Joseph Eisenberg]

The OpenStreetMap community has long agreed that mapping cadastral parcels
(land ownership) is not in scope. Protect area and National Park boundaries
were supposed to be less difficult to confirm and more valid.

But if what we are going to start mapping in the USA is simply the federal
ownership of land, that's just pure cadastre data. We might as well try to
map all the private land parcels and keep that information accurate - but
both tasks are too difficult, and the data is better provided by local
governments directly.

- Joseph Eisenberg

On Mon, Aug 31, 2020 at 9:50 PM Bradley White 
wrote:

>  If you drive into a checkerboard
>> area of private/public land, there are no Forest Service signs at the
>> limits of private land.
>>
>
> In my neck of the woods, USFS owned land is signed fairly frequently with
> small yellow property markers at the boundaries.
>
> Privately owned land within a NF declared boundary is not under any
> protection by the USFS, therefore tagging the administrative boundary as
> 'protected_area' will lead to inaccuracies. The land areas that are
> actually protected from development/have active resource management are
> only the lands which the federal government owns within these
> administrative boundaries.
>
> I think using the administrative boundaries is a good & practical first
> approximation, but the goal should eventually to be to change over to the
> actual land owned by the Fed and operated for conservation by the USFS.
>
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

[Joseph Eisenberg]

But the Forest Service itself is showing the outer boundary on it's
websites, as I've mentioned above. On the higher resolution web map, there
is only a faint difference in lighter green / darker green color to show
which land within the official boundary is privately or federally owned,
and this distinction is not even mentioned in the map legend:

https://www.fs.usda.gov/detailfull/klamath/maps-pubs/?cid=fseprd533703&width=full


And my experience is that only the outermost boundary has official signs
saying "entering Klamath National Forest". If you drive into a checkerboard
area of private/public land, there are no Forest Service signs at the
limits of private land.

- Joseph Eisenberg

On Mon, Aug 31, 2020 at 4:36 PM Kevin Kenny  wrote:

> On Mon, Aug 31, 2020 at 7:11 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> I believe there might be an issue with these complex multipolygons which
>> is preventing osm2pgsql from handling them. Perhaps it is because nodes are
>> shared between two outer rings?
>>
>> However, I also want to note that it is not clear to me that the new
>> mapping is correct.
>>
>> The new outer boundaries for the Superior National Forest are very
>> complex and only cover a small portion of the land within the National
>> Forest outer boundary:
>>
>> https://www.openstreetmap.org/relation/11558095
>>
>> Compare the official National Forest web map:
>> https://usfs.maps.arcgis.com/apps/webappviewer/index.html?id=03a17ac9df1a4cd0bcc872ac996e7231
>> - this matches the older, simpler boundary that was in OpenStreetMap
>> previously. Also see this map on the Forest website:
>> https://www.fs.usda.gov/Internet/FSE_MEDIA/stelprdb5130373.pdf
>>
>> It appears that the new, complex relation is attempting to map what land
>> is owned by the Federal government, rather than mapping the legal boundary
>> of the National Forest. Is that correct?
>>
>> I believe this is a misinterpretation of the meaning of
>> boundary=protected_area.
>>
>
> They're both 'legal' boundaries.
>
> The simple outer boundary of a National Forest is 'the area in which the
> Forest Service is authorized to purchase land without a new Act of Congress
> expanding the forest.'  It's not signed in the field and has very little
> effect upon the actual land management. It's generally all that the
> enabling act of Congress specifies; the rest is done by having the law
> authorize the Executive Branch to determine the status of parcels within
> the legislated boundary.
>
> The outer boundary also generally excludes all 'inholdings' - private
> holdings that are enclosed by the national forest.
>
> It gives a more pleasant rendering at low zoom levels while still giving a
> sense of where the National Forest is, but does not reflect the situation
> in the field.
>
> The 'patchwork quilt' area is the area actually owned by the Federal
> Government and administered by the Forest Service. It's normally what will
> be posted in the field, and it's the area that actually enjoys the
> protection.
>
> For many Federally-administered land areas, there's also a third category:
> land on which the Federal government owns a conservation easement
> (essentially, the right to develop the land) but the land ownership (the
> right to exclude others) is private. There are huge pieces of wildlife
> refuges where Uncle Sam owns the hunting and development rights, but some
> farmer or forester owns and works the land.
>
> Most people in the general public would recognize only the most
> restrictive definition in the field, since that is what's signed. A duck
> hunter would look at an official map to see which of the private parcels
> comprising a wildlife refuge are open to the public for hunting in season.
> Very few people except the real estate lawyers care about the outermost
> boundary, except to give something that can yield a readable rendering on
> small-scale maps.
>
> I'm all for making the boundary follow the legal designation that has the
> greatest effect and is visibly signed.
> --
> 73 de ke9tv/2, Kevin
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trouble with getting Superior National Forest boundary to render on standard map

[Joseph Eisenberg]

I believe there might be an issue with these complex multipolygons which is
preventing osm2pgsql from handling them. Perhaps it is because nodes are
shared between two outer rings?

However, I also want to note that it is not clear to me that the new
mapping is correct.

The new outer boundaries for the Superior National Forest are very complex
and only cover a small portion of the land within the National Forest outer
boundary:

https://www.openstreetmap.org/relation/11558095

Compare the official National Forest web map:
https://usfs.maps.arcgis.com/apps/webappviewer/index.html?id=03a17ac9df1a4cd0bcc872ac996e7231
- this matches the older, simpler boundary that was in OpenStreetMap
previously. Also see this map on the Forest website:
https://www.fs.usda.gov/Internet/FSE_MEDIA/stelprdb5130373.pdf

It appears that the new, complex relation is attempting to map what land is
owned by the Federal government, rather than mapping the legal boundary of
the National Forest. Is that correct?

I believe this is a misinterpretation of the meaning of
boundary=protected_area.

See images at
https://github.com/gravitystorm/openstreetmap-carto/issues/4198#issuecomment-684084296
for another example with the Manistee National Forest, which used to be
mapped in a much simpler fashion and now has been re-made as many smaller
parcels.

- Joseph Eisenberg

On Sun, Aug 30, 2020 at 4:22 PM Clifford Snow 
wrote:

> Paul,
> I don't have a definitive answer for you, but rendering usually takes a
> while for large areas. I would expect it to render when zoomed in but
> wasn't able to see any rendering on a couple of spot checks. I did notice
> that around islands either the forest or the island, are shifted. I would
> recommend cleaning those up.
>
> Clifford
>
> On Sun, Aug 30, 2020 at 1:19 PM Paul White  wrote:
>
>> Hello,
>>
>> I recently added the (super complicated) Superior National Forest
>> boundary to OSM, because I noticed it was missing. However, it refuses to
>> render on the standard map, even though I ran it through JOSM's validator
>> with no problems. (link to relation)
>> <https://www.openstreetmap.org/relation/11558095#map=6/48.422/-92.439> I
>> don't think it's due to the amount of members, because the Tongass National
>> Forest I added recently, with over 10,000 members, renders fine. And I know
>> it's not due to the tags on the relation; they are standard to other
>> national forests.
>>
>> If someone could look into it and see what's causing it to break, that
>> would be great.
>>
>> pj
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Joseph Eisenberg]

Is the track closed to everyone, or is it perhaps access=private, if the
landowner has access?

There is also a more specific tag for military bunkers: military=bunker

https://wiki.openstreetmap.org/wiki/Tag%3Amilitary%3Dbunker

- Joseph Eisenberg

On Sun, Aug 30, 2020 at 12:16 PM brad  wrote:

> Agree, it seems pretty clear.   Even if the signs are universally
> ignored,  OSM shouldn't mislead everyone about the legality.
>
> On 8/30/20 12:01 PM, Frederik Ramm wrote:
> > Hi,
> >
> > "Devil's Slide Bunker" is a WW2 observation point near Pacifica in San
> > Mateo County in California.
> >
> > OSM has the bunker listed as a "tourism=viewpoint", along with access
> > tracks from the nearby CA-1 highway:
> >
> > https://www.openstreetmap.org/#map=19/37.56868/-122.51506
> >
> > The area is technically on private ground, and a sign at the location
> says:
> >
> > "Warning. Hiking or climbing prohibited in this area. This property is
> > designated as a dangerous area. It shall be unlawful to trespass
> > thereon. San Mateo County Ordinance No. 1462"
> > (http://www.remote.org/frederik/tmp/dssign.jpg)
> >
> > At the same time, searching the web shows tons of tourist guides that
> > recommend a visit to this prohibited place, replete with photos showing
> > lots of people around, and "Devil’s Slide Bunker sits on private
> > property and is technically not open to the public, but a nearby parking
> > area for the Devil’s Slide Trail, easy access along a short dirt trail,
> > and no fencing mean that people stop to check it out and walk around
> > every day."
> >
> > The DWG has received a complaint from a concerned citizen (via
> > AllTrails) complaining about this illegal tourist attraction on OSM.
> >
> > While it is undeniably a de-facto tourist attraction, and undeniably
> > offers great views, I think it should probably be changed to
> > historic=ruins, access=no, and the tracks leading up to it should also
> > be changed to access=no.
> >
> > Opinions?
> >
> > Best
> > Frederik
> >
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

>  Coconino's boundary IS rendering, but with more accurate tags, and
differently than a national_park

That's incorrect. It's not rendering at all on the highest zoom levels,
which have been refreshed most recently.

boundary=national_park and boundary=protected_area are rendered identically
in the relevant map style:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/admin.mss#L496

- Joseph Eisenberg

On Thu, Jul 16, 2020 at 10:55 AM stevea  wrote:

> On Jul 16, 2020, at 10:13 AM, Joseph Eisenberg 
> wrote:
> > It's not the tagging. Other relations with boundary=protected_area +
> protect_class=6 are rendering fine in the OpenStreetMap Carto style. The
> code is here:
> https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149
> - boundary=protected_area + protect_class=6 is enough.
>
> To repeat myself, I believe Joseph and I agree / are saying largely the
> same thing here:  there isn't anything to "fix," as boundary=protected_area
> + protect_class=6 renders fine in Carto, and that is how Coconino is now
> (more correctly) tagged.
>
> Given the recent history of this multipolygon's tags being changed from
> national_park to protected_area (both of which render, but slightly
> differently), if original poster Paul wants to add clarity to why he
> believes this "isn't rendering anymore" I welcome what he might add or
> additionally ask.  However, I believe the relevant issues to be addressed
> have been.  The answer is "Coconino's boundary IS rendering, but with more
> accurate tags, and differently than a national_park, which is how it was
> previously though incorrectly tagged."
>
> SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

It's not the tagging. Other relations with boundary=protected_area +
protect_class=6 are rendering fine in the OpenStreetMap Carto style. The
code is here:
https://github.com/gravitystorm/openstreetmap-carto/blob/5724017f5b549ba954d9d645c0b2383dd16237d1/project.mml#L1132-L1149
- boundary=protected_area + protect_class=6 is enough.

– Joseph


On Thu, Jul 16, 2020 at 6:24 AM stevea  wrote:

>  Paul White  wrote:
> > Does anybody know why the Coconino National Forest doesn't render on
> osm.org anymore? I don't see any recent changes that would've messed
> anything up but it's gone. I also noticed that the Klamath National Forest
> is gone, as well.
>
> I'm glad to see august and more-technical members of OSM (Paul Norman,
> Joseph Eisenberg...) chiming into this thread.
>
> I am the most recent author of this relation.  I made minor changes to the
> tags on the relations, not the members or their roles.  Specifically, the
> edit History (click View History link at bottom of object "pane") displays
> the previous set of tags (and seems to have rendered to the o.p.'s liking),
> which included:
>
> boundary=national_park + boundary:type=protected_area
>
> while the present tags exclude those, but include:
>
> boundary=protected_area + protect_class=6
>
> I did this because boundary=national_park is not a valid tag on a USFS
> National Forest per our evolving wiki
> https://wiki.osm.org/wiki/United_States/Public_lands , which
> prescriptively suggests this tagging.
>
> I believe it is safe to assume that the previous tagging of
> boundary=national_park was incorrectly applied because it rendered, and
> that the somewhat clumsy and collides-with tag boundary:type=protected_area
> was added to be more consistent with the newer tagging scheme of
> protected_area, though it excluded the associates-with tag of
> protect_class=6 which my newer tagging added, along with the "proper" key
> of boundary, not boundary:type.  If you followed all that, thank you.
>
> The particular combination of boundary=protected_area + protect_class=6
> does render (as a thin green line and an occasional name=* value along
> edges).  And again, boundary=national_park renders, though differently than
> boundary=protected_area + protect_class=6 — and rightly so, as these ARE
> different entries:  a national park is not a national forest and vice versa.
>
> > If anyone knows how to fix this, let me know.
>
> I believe there isn't anything to "fix" here:  what appears to have
> happened is that a wrong-tagging which rendered with a certain appearance
> was corrected to be "more properly" tagged, and this renders, but
> differently.  As these are issues which may continue to be evolving
> (relatively newer tagging schemes like protected_area compared to
> national_park, as well as rendering support, or lack thereof, for various
> values of protect_class), it is possible I lack full clarity into either
> the present exception of or intended effects of these tags and the Carto
> renderer.  Here, I only offer my best explanation of present tagging and
> rendering effects, not future ones.
>
> SteveA
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Joseph Eisenberg]

Re: "recursion limits of the geometry assembler." - is this merely due to
the large number of inner and outer ways?

Is it related to the nodes that are shared by 2 outer ways?

– Joseph E.

On Wed, Jul 15, 2020 at 3:24 PM Paul Norman via Talk-us <
talk-us@openstreetmap.org> wrote:

> On 2020-07-15 3:00 p.m., Paul White wrote:
>
> Does anybody know why the Coconino National Forest doesn't render on
> osm.org anymore? I don't see any recent changes that would've messed
> anything up but it's gone. I also noticed that the Klamath National Forest
> is gone, as well.
>
> I assume you're talking about
> https://www.openstreetmap.org/relation/10956348#map=15/35.1483/-111.6705?
> It is rendered - you can see the green outline and text.
>
> https://www.openstreetmap.org/relation/11239975 is a different issue. It
> looks like it might be complex enough that it hits the recursion limits of
> the geometry assembler.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Joseph Eisenberg]

> I was thinking just create separate polygons for inholdings, tagged with
access=private and possibly ownership=private

While many Americans like to put "no trespassing" signs on their private
property, a privately owned parcel is not access=private unless there are
signs on the roads and paths leading into it which say so.

Many privately-owned parcels in the national forests are used for forestry
only, and there is no issue with crossing through on a road or trail in
many cases.

Generally it is difficult to maintain land ownership data in OpenStreetMap.
Fortunately, in the USA there are publicly-available databases which
contain this cadastral information, so it is not necessary for us to
duplicate it in OpenStreetMap. Database users should expect to get land
ownership information directly from official sources, if they want accurate
and up-to-data land ownership info by parcel.

For example in Oregon you can get data at
https://www.oregon.gov/geo/Pages/sdlibrary.aspx

We should not try to map all land ownership data by parcel in OpenStreetMap.

– Joseph Eisenberg

On Sat, Jun 20, 2020 at 5:23 PM stevea  wrote:

> Mike, I hadn't considered that, it distinctly deepens the discussion.
> Stroking my chin and saying "hm" now.
> SteveA
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import of addresses for San Francisco, CA

[Joseph Eisenberg]

Legally in San Francisco does the address refer to the property, the
building, or the entrance?

While I'm from California originally, I admit that I don't know the
definition of an address there.

If one building can have more than one address (based on separate
entrances), then it would be best to use nodes.

- Joseph Eisenberg

On Thu, Jun 18, 2020 at 9:36 AM Yury Yatsynovich 
wrote:

> I saw addresses in SF mapped both ways -- some are mapped as nodes inside
> the buildings or on contours of buildings (as entrances); others are added
> directly on the ways/relations of buildings.
>
> On Thu, Jun 18, 2020 at 12:20 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> >  matching buildings to address points
>>
>> I support the idea of adding missing addresses. However, is it best
>> practice to match the address with the building area?
>>
>> Currently in SF are almost all addresses matched with buildings, or are
>> some mapped as nodes or separate area features?
>>
>> -- Joseph Eisenberg
>>
>> On Thu, Jun 18, 2020 at 8:30 AM Yury Yatsynovich <
>> yury.yatsynov...@gmail.com> wrote:
>>
>>> Greetings!
>>>
>>> I've been recently thinking about importing addresses for San Francisco,
>>> CA.
>>> It looks like there has been interest in this kind of import (the page
>>> devoted to it was created in 2010,
>>> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).
>>>
>>> So, please, consider this message as my "community buy-in": does anyone
>>> have any objections related to this possible import?
>>> By now I've obtained a permit from the data owner (
>>> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p)
>>> and almost finished writing my code for matching buildings to address
>>> points.
>>>
>>> If there are no objections, I'll go on with organising all documentation
>>> and sharing the code/resulting .osm-files for review by OSM community.
>>>
>>> Looking forward to receiving your feedback!
>>>
>>> p.s. I have some experience in importing addresses (e.g., see
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)
>>>
>>>
>>>
>>>
>>> --
>>> Yury Yatsynovich
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>
> --
> Yury Yatsynovich
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Google earth, Google maps

[Joseph Eisenberg]

You should check the measurement directly from aerial imagery in iD or
JOSM, or by visiting the location in person and measuring or estimating.

On Sat, Jun 13, 2020 at 9:24 AM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> since the complainer removed the source (google map) do i remove the # as
> well ?
>
>
>
> Saturday, June 13, 2020 11:09 AM -05:00 from Mike Thompson <
> miketh...@gmail.com>:
>
>
>
> According to the Google Maps Terms of service, you cannot use it in any
> way to make another map. [0]  I would think that would include using its
> ruler if the purpose of using the ruler is to edit OSM.
>
> [0] 2.d of https://www.google.com/help/terms_maps/
>
> On Sat, Jun 13, 2020 at 9:47 AM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> because i was asked to change my edit based on my own ruler measurement,
>
> but it was just a ruler on google maps.
>
>
> Saturday, June 13, 2020 10:42 AM -05:00 from Mateusz Konieczny via Talk-us
>  >:
>
> If you were not copying Google Maps then why you were using the ruler?
>
> Why using ruler on Google Maps would be even necessary?
>
> Jun 13, 2020, 17:31 by t...@openstreetmap.org
> :
>
> i put them as a source i used a ruler on there map.
>
>
>
> Saturday, June 13, 2020 10:20 AM -05:00 from Mateusz Konieczny via talk <
> t...@openstreetmap.org >:
>
>
>
>
> Jun 13, 2020, 16:59 by eric.lad...@gmail.com
> :
>
> Yeah, be careful with Google Maps.  It's owned and created by a company
> and if you copy from it and they can prove it, they could sue the OSM
> Foundation into oblivion.  They used to even have their OWN satellites to
> obtain imagery.  That's serious money.
>
> That is not the main problem. Main problem is that it goes our own
> fundamental rules.
> Mappers must not use other maps* even if whoever hold copyright is unable
> to sue for some reason.
>
> And "they can prove it" part may be misleading - you are not allowed to
> copy even if you think that
> you can hide the copying so that noone will notice it.
>
> *that is more complicated, we are must not copyrighted data on
> incompatible licenes -
> but if you are unsure what it means do not use other maps and ask for help
> before doing this
>
>
> Typically, with local edits, I put "Local knowledge" as the source.
> Sounds more highbrow than "my eyeballs".
>
> I usually put survey/memory depending on how recent my data is.
>
> IMO, if somebody is challenging one of your local edits, if they are not
> local also, they should be told as much and sent on their way - UNLESS it's
> something that relates to a mapping standard or best practice.  Then, learn
> from your mistakes and move on.
>
> +1
>
> On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org> wrote:
>
> this was a tool on the map that measured distance.
>
> Have you copied that map? I am unsure how the distance measuring tool
> relates to "why are you telling me I can not use google as a map source"?
>
>
>
> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us <
> talk-us@openstreetmap.org>:
>
> You are not allowed to use Google Maps as source.
>
> Have you used Google Maps to edit OSM?
>
> "since all the maps on OSM are old news like in my local area 7 months
> old."
>
> FYI, world is larger than your local area.
>
>
> Jun 13, 2020, 16:08 by talk-us@openstreetmap.org:
>
> If you people want me to prove my edit by adding a source, and a person
> from the data group as an editor,
>
> asks me to prove it, and i redo my edit and he does not get back to me,
> why are you telling me I can not use
>
> google as a map source, since all the maps on OSM are old news. like in my
> local area 7 months old.
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> --
> Eric Ladner
>
>
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/talk-us
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.o

Re: [Talk-us] Off-highway vehicle recreation areas

[Joseph Eisenberg]

A leisure=park is supposed to be similar to a town park; an area with
managed vegetation where you might walk around or recreate. An OHV area is
not like this: "A park is an area of open space for recreational use,
usually designed and in semi-natural state with grassy areas, trees and
bushes. ... This tag is intended for (usually urban) parks with managed
greenery, located within settlements and nearly always open to general
public."

The tag leisure=sports_centre might be appropriate for an area that is
specifically developed and designed for ATVs and motorcycles.

"A *sports centre* is a distinct facility where sports take place within an
enclosed area. It can be a building (indoor sports centre), just outside
(outdoor sports centre) or contain indoor and outdoor sports features mixed
together."

However, if this is a large semi-natural area that just happens to have a
number of track or trails, then it's similar to a forested area with hiking
trails or mountain bike paths. In this case it might or might not be part
of a boundary=protected_area

In the case of the Hungary Valley SVRA, it is managed by the California
State Parks system: https://www.parks.ca.gov/?page_id=405 - I believe this
is a boundary=protected_area

-- Joseph Eisenberg

On Sat, Jun 6, 2020 at 12:54 PM brad  wrote:

> Good question.   At first glance I don't think Leisure=park is wrong.  The
> wiki is characteristically narrow since it says that it is green.
> leisure=sports_center or landuse=recreation_ground would be better.
> leisure=pitch doesn't seem right even thought the sport=motocross wiki page
> references it.   These OHV areas are typically more than a simple motocross
> track.   leisure=nature_reserve sure doesn't seem right!
>
> On 6/5/20 4:55 PM, Tod Fitch wrote:
>
> I have noticed a couple of off-highway vehicle recreation areas that are 
> tagged with things that seem incorrect to me: As generic parks or as 
> protected areas.
>
> Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the 
> Wildomar OHV Area [5][6].
>
> My problem is that I can’t tell from the wiki and taginfo what might more 
> appropriate or more accepted tagging. It seems there is tagging for tracks 
> used for motocross. And people have used access tags for ATVs. But I don't 
> see a documented tagging for an area that contains a trail system for use by 
> multiple types of off-highway vehicles. I have some thoughts on what might be 
> appropriate, but would rather hear from others.
>
> Thanks!
>
> --Tod
>
> [1] 
> https://www.riderplanet-usa.com/atv/trails/info/california_10003/ride_413b.htm
> [2] https://www.openstreetmap.org/relation/6179378
> [3] https://www.openstreetmap.org/way/367714413
> [4] https://www.openstreetmap.org/way/367714414
> [5] 
> https://www.riderplanet-usa.com/ATV/trails/info/california_03947/ride_7684.htm
> [6] https://www.openstreetmap.org/way/248540505
>
>
> ___
> Talk-us mailing 
> listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

>  should the entirety of the underlying area be tagged landuse=farmland or
landuse=residential?

Neither: just tag the areas that are used for residences as
landuse=residential, and the area used for farming (mostly crops) as
landuse=farmland.

In OpenStreetMap we want to map what is actually there, not the zoning or
legal landuse or property boundaries.

This might change next year, just like an unmown meadow may change back
into scrubland, and then eventually into woodland, or how a river will
meander over time.

Map what is there in reality right now, to your best ability. If people
want to know the legal zoning or property boundaries there are plenty of
data sources for that information, but OpenStreetMap is valueable because
it provides local knowledge of what is really there.

–Joseph Eisenberg

On Tue, Jun 2, 2020 at 1:19 PM stevea  wrote:

> Mateusz Konieczny  wrote:
> > I think that it is not a good assumption. One may have a property
> boundary that is partially landuse=residential and partially
> landuse=industrial/farmland
>
> I have mentioned before that the values OSM documents for the landuse key,
> while good, are incomplete with the great richness by which the world
> recognizes and categorizes these.  Here, Mateusz mentions a "triple" where
> residential, industrial and farmland exist together (or perhaps "double"
> where the latter two are blended, a certain kind of "single" activity, so
> when the residence is added, this makes two distinct landuses in total).
>
> I myself have mentioned what are locally known as "residential /
> agricultural" areas, which I characterize as a "live on family farm."
> These consist of a residence (house) and small (one to ten hectares) or
> medium-to-large (ten hectares and larger) areas where a wide variety of
> agriculture either can or might take place.  Some areas are substantially
> tree-covered and give rise to wild mushroom gathering, what I am told is a
> "fruits of the forest" activity, not "farmland."  On these (especially in
> clearings, grassland/meadow areas), I often find
> landuse=greenhouse_horticulture, landuse=orchard and landuse=vineyard areas
> which "crop up" and appear in imagery.  Because OSM has specific tags for
> these, I tag them as I see them.  However, should the entirety of the
> underlying area be tagged landuse=farmland or landuse=residential?  The
> truth is, "they are both," but OSM hasn't a
> landuse=live_on_family_farm_that_gives_rise_to_tree-planting_viticulture_and_hothouses
> tag.
>
> Getting the entirety of the world to agree upon values which seem very
> highly locally-dependent and articulated seems difficult.  The alternative
> is to have our renderers only approximate the tagging mappers are
> encouraged to "shoehorn" into, given these many, often subtle, landuse
> distinctions.
>
> Another complicating factor is "actual landuse" vs. "potential landuse,"
> (does take place vs. can or might take place) where some say to "tag only
> what is actual."  Others see this approach as a removal of land rights,
> further muddying what OSM means by landuse.
>
> These issues truly are complicated, I believe it is easy to agree.
>
> SteveA
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Stay-Healthy Streets in Seattle do not appear to be Living Streets

[Joseph Eisenberg]

Some mappers have suggested using highway=living_street for streets in
Seattle (and perhaps elsewhere) which temporarily have through-traffic
restricted for motor vehicles. However, this appears to be incorrect usage
of the tag.

According to the announcement by SDOT, the streets in the Stay-Healthy
Streets program have a speed limit of 32 kph (20 mph), much higher than the
maximum for a Living Street (20 kmh to "walking speed"). It appears that
the legal change is that these streets are now motor_vehicle=destination,
with through-traffic prohibited, but they are not Living Streets according
to the description in this page or at Wikipedia:

"designed primarily with the interests of pedestrians and cyclists in mind
and as a social space where people can meet and where children may also be
able to play legally and safely... vehicle parking may be restricted".
"These streets are often built at the same grade as sidewalks, without
curbs. Cars are limited to a speed that does not disrupt other uses of the
streets (usually defined to be pedestrian speed), or through traffic is
eliminated using bollards or circuitous one-way operation. To make this
lower speed natural, the street is normally set up so that a car cannot
drive in a straight line for significant distances, for example by placing
planters at the edge of the street, alternating the side of the street the
parking is on, or curving the street itself. Other traffic calming measures
are also used."

The streets in Seattle have street parking along their whole lengths, and
there are no design changes compared to other highway=residential streets
in the city, except for signage / paint.

While I would personally love to see real Living Streets in the USA, it
doesn't appear that this tag should be used in Seattle (or Portland, where
we have implemented similar short-term policies on "Neighborhood
Greenways") at this time. If the city redesigns these streets and lowers
the speed limit to 5 or 10 mph and legally allows pedestrians to use the
whole street at any times, then we can reconsider.

–Joseph Eisenberg
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

Could you provide a link to a particular location you are thinking of?

When I map farms in Papua, Indonesia, usually there is a central
residential compound with a few small houses and farm buildings, and
usually some shade and fruit trees right between the houses. I map that
residential area as landuse=residential. Sometimes there is a yard for
raising chickens and pigs or a large pig stye and dirt area nearby; that
can be mapped as landuse=farmyard. Then if there are vegetables gardens I
map those as landuse=farmland. Any fields planted with bananas or (fruit)
palms are landuse=orchard. Fallow fields are usually landuse=meadow if they
are covered in grass, though after a few years they turn back into
natural=scrub and eventually natural=wood - the locals use a very long
rotation period.

So, each area is mapped with what it is used for. This means that the
different landuse areas can be pretty small. E.g.:
https://www.openstreetmap.org/#map=17/-4.08508/138.73589

In the parts of Europe I've seen even smaller patches of different areas:
https://www.openstreetmap.org/#map=17/38.55129/-28.66001
That looks like a lot of work! It's totally okay to start by just mapping
large areas imprecisely, and then later we can get it down to very precise
mapping of thin strips of trees and scrub between fields:
https://www.openstreetmap.org/way/628402941 - if we want to

Joseph

On Thu, May 28, 2020 at 6:48 PM stevea  wrote:

> On May 28, 2020, at 5:12 PM, Joseph Eisenberg 
> wrote:
> > >  beekeeping, wild mushroom harvesting, herb-crafting for essential oils
> >
> > Those are all forest products, not so much farm products (though honey
> can come from any type of vegetation):
>
> So, do I use landuse=forest or the current landuse=farmland?  What I hear
> is that I must choose between landuse=forest and landuse=residential.  I
> describe "live on family farms in the forest which are partially though not
> necessarily rather forested areas which give rise to many kinds of
> agricultural production, right now, today, flexibly, as we speak."  They
> support families in residential areas simultaneously to whatever seemingly
> singular value I must compress into.  They flexible support vineyards,
> orchards and greenhouse_horticulture.  But, sir, who are you to ask where
> the edge of their residential aspect exists?  I say and property owners say
> (apparently, some renderer authors disagree, and that's certainly OK, I'm
> merely trying to understand it) expound 'the residential semantic' over the
> entire domain.  Anything else, to what we might loosely agree as Americans
> is a "5th amendment taking of property rights by the government."  If that
> sounds political, I guess that's where I say, "OK, diverges from Carto."
> Again, that's OK.  This is about me, Steve, understanding it.
>
> There is such a thing as "family owned 'farm' in the forest which does and
> might give rise to forest products and has some trees where people live in
> small family clusters in residential buildings."  If I need to fit all that
> into a single landuse tag I'd like you to tell me what it is and how it
> renders.  Families and agriculture and human life here on Earth is so much
> more complicated than that.  Thank you.
>
> > "Forest products include materials derived from a forest for commercial
> and personal use such as lumber, paper, and firewood as well as “special
> forest products” such as medicinal herbs, fungi, edible fruits and nuts,
> and other natural products."
> >
> > So, land covered with trees which is used to produce mushrooms,
> truffles, herbs, essential oils, honey, cork, bark, firewood, etc - that's
> forest or woodland, not landuse=farmland.
>
> OK, but people live here, too.  Which landuse value (with farmland out of
> the way), forest or residential?  I shouldn't have to choose.
>
> > > > Yes, the same area may be tree covered and residential at the same
> time.
>
> Of course, there are many of these.  How do we tag them?
>
> > > Yet, Mateusz, you don't say exactly how to tag these.
> >
> > You can just overlap them. Don't worry too much about how OpenStreetMap
> carto renders it, as long as they way you map it makes sense and matches
> reality. Perhaps we can fix the rendering if the current results are
> causing confusion, so that the trees only show when the green background
> shows.
>
> Examples of "how these are properly overlap" are appreciated.
>
> Changing how these layers render now would even-more-confuse.  Let's stick
> to how they do now.
>
> > > a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage,
> a small cleari

Re: [Talk-us] Heavily-wooded residential polygons

[Joseph Eisenberg]

>  beekeeping, wild mushroom harvesting, herb-crafting for essential oils

Those are all forest products, not so much farm products (though honey can
come from any type of vegetation):

"Forest products include materials derived from a forest for commercial and
personal use such as lumber, paper, and firewood as well as “special forest
products” such as medicinal herbs, fungi, edible fruits and nuts, and other
natural products."

So, land covered with trees which is used to produce mushrooms, truffles,
herbs, essential oils, honey, cork, bark, firewood, etc - that's forest or
woodland, not landuse=farmland.

> > Yes, the same area may be tree covered and residential at the same time.

> Yet, Mateusz, you don't say exactly how to tag these.

You can just overlap them. Don't worry too much about how OpenStreetMap
carto renders it, as long as they way you map it makes sense and matches
reality. Perhaps we can fix the rendering if the current results are
causing confusion, so that the trees only show when the green background
shows.

> a 10 hectare / 25 acre parcel which is 98% trees and 2% house, garage, a
small clearing

Yeah, I would only map the cleared area as landuse=residential in that
case, since the rest of the land is being used to grow trees, not for
residential purposes. While the current owner may not plan to cut firewood
or timber, the next owner might in another 20 or 30 years. Forestry is a
long-term thing.

> 0% row crops, but allows (and actually develops) into orchards,
vineyards, greenhouse_horticulture.

It does not matter what is allowed by the local zoning laws. Don't map
zoning in OpenStreetMap, map what is actually there in reality. So, if they
plant a vineyard, map that as landuse=vineyard. But don't map
landuse=vineyard just because it's allowed to plant a vineyard someday.

– Joseph Eisenberg

On Thu, May 28, 2020 at 3:51 PM stevea  wrote:

> Mateusz Konieczny writes:
> > (quoting stevea)
>  "treed farmland" or "heavily wooded residential" prove slightly
> problematic to OSM tagging.
>
> Then, Mateusz Konieczny answers:
> > Map tree-covered area (landuse=forest) and map farmland
> (landuse=farmland) or residential (landuse=residential).  Yes, the same
> area may be tree covered and residential at the same time.
>
>
> If only it were this simple, it appears not to be.  "Tree covered area"
> can be either landuse=forest (OSM's wiki defines something like a
> half-dozed different conventions on how we actually tag this) OR it can be
> natural=wood.  Very roughly stated, what _I_ do (as I see other California
> and USA-based users doing this — I'm not trying to invent a new tagging
> method) is to map distinctly "timber production" areas as landuse=forest
> and distinctly "appears to be wooded — whether pristine and ancient
> never-cut forest I don't necessarily know — as natural=wood.  That is for
> starters and only attempts to start from a point of "visible trees" (as in
> imagery) while only leaning in the direction of landuse in the aspect of
> landuse=forest being "it is well-known that this is an area which is either
> actively forested, or has the right to have its trees felled" (timber
> permits, owned by a logging company, CAN be cut but maybe are still growing
> to maturity, MIGHT be cut but could also be deeded by owner later on to
> become conservation or land trust protected area...).  The possibilities
> are myriad, but OSM does a "fair to good" job of characterizing these, and
> with only two tags, forest and wood.  This isn't perfect nor is the
> consensus about how we do it, so that aspect alone complicates this
> question, while at least providing SOME stability of understanding the
> complex semantics.
>
> THEN there is the aspect of ALSO-has-a-residential-aspect (or perhaps
> PRIMARILY does).  Clearly, a 10 hectare / 25 acre parcel which is 98% trees
> and 2% house, garage, a small clearing and a driveway for access is
> something quite different than natural=wood (as far as its residential
> landuse goes).  However, it might not be all that different than a
> landuse=forest, ESPECIALLY if the residential land owner also has a timber
> permit to cut trees (possible, though not necessarily common, at least
> around here).
>
> Regarding farmland, this has also been discussed many times, especially
> about Santa Cruz County (see that topic's wiki, the fifth paragraph of the
> "Work to be done in the County" section).  Briefly, misunderstandings
> happen because around here, we have areas which are zoned farmland, (and
> are actually areas of — among other agricultural activities — beekeeping,
> wild mushroom harvesting, herb-crafting for essential oils, oth

Re: [Talk-us] Relation template for an honorary/memorial highway?

[Joseph Eisenberg]

All US Interstate Highways are part of the Dwight D. Eisenhower Highway
system, just like they are all part of the Pan-American Highway System.
Neither of these names should be tagged in OpenStreetMap, because they are
not used on signs or by locals.

This information is appropriate for Wikidata and Wikipedia, rather than
OpenStreetMap.

-Joseph

On Tue, May 26, 2020 at 2:43 PM Jack Armstrong 
wrote:

> Sorry. I typed Theodore Roosevelt, but I meant to type, Dwight D.
> Eisenhower Highway. It's the Dwight D. Eisenhower Highway that gives me the
> biggest headaches and longest discussions every time it comes up.
>
> https://www.fhwa.dot.gov/infrastructure/ddehwy.cfm
>
> I thought official_name=* was for country names, but I'm also hesitant to
> use it as I think an interstate highway such as, I-70 would render the
> name, "Dwight D. Eisenhower Highway" on maps when it's not actually used
> by locals nor used on any signage.
>
> I certainly have no desire to spend the time creating relations,
> especially if it's not considered a best practice. I'm just looking for a
> way to avoid so many long discussions (and sometimes arguments) about these
> honorary/memorial names that aren't actually used but were created by some
> obscure congressional bill long ago.
>
> Cheers
>
>
> -Original Message-
> From: Joseph Eisenberg
> Sent: May 26, 2020 2:54 PM
> To: Jack Armstrong
> Cc: Talk us
> Subject: Re: [Talk-us] Relation template for an honorary/memorial highway?
>
> Only real, current features should be mapped, but it's possible to add
> "official names" even if they are not the commonly used name, as long as
> they are documented on signs.
>
> It looks like some of these are historic only:
> https://en.wikipedia.org/wiki/Theodore_Roosevelt_International_Highway -
> historic, no longer exists
>
> And the Pan-American Highway system officially includes all the
> Interstates in the United States, but has no signage. So there is not an
> appropriate way to map this in OpenStreetMap:
> https://en.wikipedia.org/wiki/Pan-American_Highway#Contiguous_48_states_of_the_United_States
>
> But these can probably be tagged as "official_name=Ronald Reagan Highway":
> https://en.wikipedia.org/wiki/Ronald_Reagan_Highway
>
> – Joseph Eisenberg
>
> On Tue, May 26, 2020 at 12:15 PM Jack Armstrong 
> wrote:
> >
> > More than once in the past, users have attempted to “name” highways in
> Colorado as the “CanAm Highway”, the “Pan-American Highway”, the “Ronald
> Reagan Memorial Highway” and the “Theodore Roosevelt International
> Highway”, to name a few. There are other honorary/memorial highway
> designations in the area.
> >
> >
> > In order to satisfy persons who want to map these and other memorial
> highways that aren’t actually named “on the ground” here, I’m thinking
> relations might be created. This way, when this situation undoubtedly comes
> up again, I can point the user to the relation and more easily resolve any
> conflicts.
> >
> >
> > Any suggestions as to the relation template I should use? I looked at
> the interstate highway relation wiki and it doesn’t seem to be quite right.
> For example, it requires a ref - number only.
> >
> >
> > I suppose, where appropriate, a different relation should be created for
> each state the memorial highway passes through? Which network relation or
> super relation should these memorial route relations be tied into?
> >
> >
> > Any feedback is welcome. Thanks :)
> >
> >
> >
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relation template for an honorary/memorial highway?

[Joseph Eisenberg]

Only real, current features should be mapped, but it's possible to add
"official names" even if they are not the commonly used name, as long as
they are documented on signs.

It looks like some of these are historic only:
https://en.wikipedia.org/wiki/Theodore_Roosevelt_International_Highway -
historic, no longer exists

And the Pan-American Highway system officially includes all the Interstates
in the United States, but has no signage. So there is not an appropriate
way to map this in OpenStreetMap:
https://en.wikipedia.org/wiki/Pan-American_Highway#Contiguous_48_states_of_the_United_States

But these can probably be tagged as "official_name=Ronald Reagan Highway":
https://en.wikipedia.org/wiki/Ronald_Reagan_Highway

– Joseph Eisenberg

On Tue, May 26, 2020 at 12:15 PM Jack Armstrong 
wrote:
>
> More than once in the past, users have attempted to “name” highways in
Colorado as the “CanAm Highway”, the “Pan-American Highway”, the “Ronald
Reagan Memorial Highway” and the “Theodore Roosevelt International
Highway”, to name a few. There are other honorary/memorial highway
designations in the area.
>
>
> In order to satisfy persons who want to map these and other memorial
highways that aren’t actually named “on the ground” here, I’m thinking
relations might be created. This way, when this situation undoubtedly comes
up again, I can point the user to the relation and more easily resolve any
conflicts.
>
>
> Any suggestions as to the relation template I should use? I looked at the
interstate highway relation wiki and it doesn’t seem to be quite right. For
example, it requires a ref - number only.
>
>
> I suppose, where appropriate, a different relation should be created for
each state the memorial highway passes through? Which network relation or
super relation should these memorial route relations be tied into?
>
>
> Any feedback is welcome. Thanks :)
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Joseph Eisenberg]

I also think that it makes sense to have counties as admin_level=6 in
Connecticut and Rhode Island, if local people still know their counties and
the governments still recognize them for geographic, statistical and some
other legal purposes.

-- Joseph Eisenberg

On Fri, May 15, 2020 at 1:42 PM Frederik Ramm  wrote:

> (3d attempt, apologies if you should get this several times)
>
> Hi,
>
> I am tempted to revert stevea's removal of the admin_level=6 from
> counties (where this was in place for the last 10 years or so, eg
> https://www.openstreetmap.org/relation/1839542/history) until a
> consensus is found that they should actually be removed.
>
> It is clear that there is a need for discussion, and I feel that such a
> discussion should take place *before* a change is made and not *after*.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] How to map snowmobile trails in US?

[Joseph Eisenberg]

Winter-only snowmobile routes are mapped if they are signed. Create a route
relation with type=route + route=snowmobile (used 141 times) - see
https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Dsnowmobile

Please only use highway=track when there is an forestry or agricultural
road / track which is passable by 2-track vehicles such as farm tractors,
logging trucks, or 4wd cars.

-- Joseph Eisenberg

(You might try the Tagging mailing list for questions about how to tag
something: tagg...@openstreetmap.org)

On Thu, May 7, 2020 at 8:43 AM Kevin Broderick 
wrote:

> Ideally, I'd say that most snowmobile routes should be relations, not
> ways. At least in the places I'm familiar with (New England and Montana), a
> significant portion of the snowmobile trail network overlaps with seasonal
> roads that are open to wheeled traffic in some conditions. Having the
> summer ground truth mapped accurately is hugely helpful if you're poking
> around in the summer, whether it be hiking, biking, riding an on/off-road
> motorcycle, etc; as you noted, some snowmachine trails are virtually
> invisible in the summer and may even be impassable (I'm familiar with some
> spots in Vermont where the snowmachine trails transit across swamp or
> marshland once it's frozen—not something you want to try to cross on foot
> or wheeled vehicle).
>
> Around here, there's also the side issue of someone having mapped one of
> the ITS routes as a track for a long distance, when it actually should be a
> series of ways with different data, as some parts are well-maintained
> gravel roads in the summer, others are less-well-maintained, some are
> public ways and others aren't.
>
> To answer the question about sections that specifically cross fields: I'd
> still be tempted to tag that as highway=track, with appropriate access and
> surface tags. I'm not sure it's the best way to do it, but I can't come up
> with a better way, and the track in question would likely be passable with
> permission and the right vehicle.
>
> As for sections that cross [frozen] marshes, or other areas that aren't
> passable when the ground is thawed, I don't know. Maybe there is a use case
> for "highway=frozen" or something similar, as ice_road is applied to
> another way, and none of the highway= values with which  I'm familiar would
> make sense.
>
> On Thu, May 7, 2020 at 10:41 AM Bob Gambrel  wrote:
>
>> Am newby to talk-us. This may have been discussed in the past but not
>> handy with searching archives yet.
>>
>> In Minnesota I have seen snowmobile trails mapped in OSM as follows:
>>
>> highway=track
>> snowmobile=designated
>> surface=unpaved
>>
>> In both aerial photos and observation on the ground, there is almost
>> always no track visible. In the winter, with snow cover, the location of
>> the track is visible because it is compacted by snowmobiles. In the spring
>> there might be some evidence in areas with grasses that would have been
>> tamped down by the snowmobiles.
>>
>> Question: Is this the right way to map snowmobile trails? The thing that
>> concerns me, of course, is the use of "track" because of it is not apparent
>> most of the time.
>>
>> Another question: is there a forum or expert group or something that
>> discusses this? I would like to join that conversation if there is  one
>> going on.
>>
>> I think it is a good idea to map these trails. It seems there maybe
>> should be another type of highway? Something like: "not visible on the
>> ground most of the year". Note that ice_road=yes is not appropriate here
>> (in most cases) as (in most cases) these trails are not on frozen water
>> bodies.
>>
>> As further info, where I was able to observe there are a number of signs
>> posted such as stop signs, caution signs, etc. So there clearly is
>> government involvement.
>>
>> Any thoughts?
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Updating opening_hours for COVID-19.

[Joseph Eisenberg]

That's great, if you are committed to going back and changing all the
opening_hours again in a month or two.

But it could be a bad idea in the long term if there is no follow-up
to return the hours to the regular ones afterward.

- Joseph Eisenberg

On 3/14/20, Eric Christensen via Talk-us  wrote:
> I've been updating the opening_hours for businesses and services as I
> hear about them closing or changing their hours of operation for
> COVID-19.  I'm also adding a note in the description with any
> information the source is providing.
>
> Seems like a good idea to keep people updated to what's open and what's not.
>
> I wonder if anyone else is also doing this as well?
>
> --Eric
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Tagging "Junior College" or "Community College"?

[Joseph Eisenberg]

How are people tagging places known as "junior colleges" or "community
colleges?" Usually these offer 1 or 2 year associates degrees and
diplomas in specific trades or work fields, or general higher
education courses which make it possible to transfer to a 4-year
University.

Is it proper to use amenity=college? That tag was originally developed
for insitutes of "Further Education" in the UK, which are a bit
different than North American junior/community colleges. Is anyone
using amenity=university instead?

- Joseph Eisenberg

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Railway improvements; stations vs. halts

[Joseph Eisenberg]

According to the wiki page, railway=halt is mainly used for "A small
station, may not have a platform, trains may only stop on request."
The presence of points/switches is only significant in Germany.

I would recommend reverting to railway=station for any which have
platforms and are regularly scheduled places for the train to stop.

-Joseph Eisenberg

On 1/8/20, Clay Smalley  wrote:
> Hi all,
>
> Over the last few months, I've been doing some systematic improvements to
> the passenger railway network across North America. Much of this has been
> filling out public_transport=stop_area relations for every railway station,
> including stop positions and platforms, as well as verifying the geometry
> of the underlying railways and classifying them (usage=*, service=*). My
> goal here is to prepare the map such that route relations can be more
> meaningful and accurately describe which track each train uses.
>
> In the course of doing this, I got a tap on the shoulder [1] and found out
> I was using a definition of railway=halt that may not match up with what
> people were expecting. As far as I know now, railway=station was originally
> intended for stations where trains are always scheduled to stop, and
> railway=halt for flag stops (aka request stops). In the German OSM
> community, there was a decision made for railway=halt to be used on
> stations that are missing switches, which means trains cannot switch
> tracks, terminate or reverse direction there—a distinction more relevant to
> railway operations and scheduling. Naturally, there are quite a lot more of
> these than flag stops.
>
> I'm in a predicament here. So far, I've mapped all Amtrak stations and
> various commuter rail stations across the Northeast according to the
> no-switches definition of halt. I'm happy to revert these back to stations
> (wherever they aren't flag stops), though I'd like to hear others' thoughts
> before going through with that.
>
> -Clay
>
> [1] https://www.openstreetmap.org/changeset/77959450
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

Thanks, Tod.

BTW, I believe the "official_name" for all California counties is now
in the format "County of Los Angeles", right? This shouldn't be used
for the "name=" since almost everyone still puts the County last (e.g.
"Los Angeles County") in common usage, but official documents will use
the other way with "of" in the middle.

Joseph Eisenberg

On 12/28/19, Tod Fitch  wrote:
> Based on this discussion and my own checking to see what search engines are
> doing with the data, I think it would be okay to move the alt_name tag value
> to be a short_name value for the counties in California and Arizona where
> the current alt_name tag is the same string as the name but without a “
> County” suffix. For example:
>
> alt_name=“Los Angeles”
> name=“Los Angeles County”
>
> Changed to
>
> name=“Los Angeles County”
> short_name=“Los Angeles”
>
> From my side this is now just a desire to be logical and consistent (not
> always a trait seen in OSM tagging). My initial annoyance has been dealt
> with on my topo map rendering by creating a Postgresql function that, among
> other things, will ignore alt_name values if they fit the above criteria. As
> noted by Joseph Eisenberg, the alt_name/short_name value could probably be
> dropped in these cases but I suspect that will get more push back than
> changing the tag.
>
> — Tod
>
>> On Dec 27, 2019, at 7:21 PM, Joseph Eisenberg 
>> wrote:
>>
>> It's not necessary to add an alternative like "Josephine" if the name=
>> is already "Josephine County" because geocoding and search application
>> already know to search for part of a name.
>>
>> For example this search already finds the "Josephine County"
>> administrative boundary as the first result:
>> https://www.openstreetmap.org/search?query=Josephine - and there is no
>> short alt_name or short_name.
>>
>> So I think there is no reason to have this information duplicated if
>> we are just worried about search.
>>
>> -Joseph Eisenberg
>>
>> On 12/27/19, stevea  wrote:
>>> I truly love the level of detail we get "coming out of the woodwork" so
>>> that
>>> we may have excellent real-life examples to share with one another (and
>>> +1
>>> to one another, too!)
>>>
>>> To be brief about it (rare for me, I endeavor to get better):  good
>>> examples, discussion / dialog and sharing our real-world experiences and
>>> knowledge is only going to help things.  If somebody reading now has a
>>> more-concrete understanding of differences between old-, alt-,
>>> official-,
>>> and so on, hooray.  If such sharper focus finds its way into a
>>> more-enlightened sentence or paragraph in a wiki, great.
>>>
>>> Chip, chip, chipping away at it (are all of us),
>>> SteveA
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

It's fine to use short_name= if that's a commonly-used shorter name
for a feature, which might be used by a renderer when they want a more
concise name for rendering, for example, and which is still a name
that is in use locally.

I'm just mentioning that it's not necessary to add this to help search
applications only.

- Joseph Eisenberg

On 12/28/19, stevea  wrote:
> Right:  I've wondered if short_name would be appropriate in this case.  Our
> wiki says short_name would work, Joseph says "not," though I suppose it is
> ultimately up to the search machinery and what it does.  If, indeed, as
> Joseph says, it already does this (or "they" already do this), the need for
> our documented short_name value simply goes away.
>
> SteveA
>
>> On Dec 27, 2019, at 7:21 PM, Joseph Eisenberg 
>> wrote:
>>
>> It's not necessary to add an alternative like "Josephine" if the name=
>> is already "Josephine County" because geocoding and search application
>> already know to search for part of a name.
>>
>> For example this search already finds the "Josephine County"
>> administrative boundary as the first result:
>> https://www.openstreetmap.org/search?query=Josephine - and there is no
>> short alt_name or short_name.
>>
>> So I think there is no reason to have this information duplicated if
>> we are just worried about search.
>>
>> -Joseph Eisenberg
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

It's not necessary to add an alternative like "Josephine" if the name=
is already "Josephine County" because geocoding and search application
already know to search for part of a name.

For example this search already finds the "Josephine County"
administrative boundary as the first result:
https://www.openstreetmap.org/search?query=Josephine - and there is no
short alt_name or short_name.

So I think there is no reason to have this information duplicated if
we are just worried about search.

-Joseph Eisenberg

On 12/27/19, stevea  wrote:
> I truly love the level of detail we get "coming out of the woodwork" so that
> we may have excellent real-life examples to share with one another (and +1
> to one another, too!)
>
> To be brief about it (rare for me, I endeavor to get better):  good
> examples, discussion / dialog and sharing our real-world experiences and
> knowledge is only going to help things.  If somebody reading now has a
> more-concrete understanding of differences between old-, alt-, official-,
> and so on, hooray.  If such sharper focus finds its way into a
> more-enlightened sentence or paragraph in a wiki, great.
>
> Chip, chip, chipping away at it (are all of us),
> SteveA
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Joseph Eisenberg]

>  new freeway was just renamed for a congress person

In this case “official_name=“ with the whole congresspersons name would be
good, keeping the commonly-used name in “name=“.

-Joseph
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Wilderness areas separate from forest?

[Joseph Eisenberg]

I agree that the current OpenStreetMap data is wrong.

For example, I grew up in the Klamath National Forest, and that area should
include the Marble Mountain wilderness, it’s shouldn’t be a hole in the
National Forest.

-Joseph

On Thu, Dec 26, 2019 at 10:40 AM Tod Fitch  wrote:

> If I am looking at the map data correctly, it seem that at least some
> designated wilderness areas are excluded from the forest that they are in.
> For example the Chumash Wilderness [1] seems to have its border as an outer
> on the Los Padres National Forest [2].
>
> This does not seem correct to me. In this specific case the wilderness is
> administered as part of the Mt. Pinos Ranger District of the Los Padres
> National Forest. I believe the same situation exists with the San Mateo
> Wilderness in the Cleveland National Forest.
>
> What is our tagging policy on this? Should the wilderness be shown as part
> of the forest that contains it? (I realize there may be wilderness areas
> that cover multiple forests but the usual case is that a wilderness area is
> a subset of a forest both geographically and administratively.
>
> Comments?
>
> Thanks
> Tod
>
>
> [1]
> https://www.openstreetmap.org/relation/2779216#map=12/34.7913/-119.1759
> [2]
> https://www.openstreetmap.org/relation/2784140#map=11/34.7975/-119.2302
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

Thank you for the correction. So highway=trunk in German is similar to
expressway=yes in the USA?

Joseph

On Sun, Dec 22, 2019 at 6:49 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 21. Dec 2019, at 01:10, Joseph Eisenberg 
> wrote:
> >
> > Unfortunately, the road classification system in parts of Continental
> > Europe was different, so mappers in some major countries, including
> > Germany and France, chose to use highway=trunk as synonym for
> > "motorroad" (somewhat similar to a U.S.A. "expressway"), with other
> > major roads tagged as highway=primary.
>
>
> actually not, the motorroad tag was introduced by the Germans (AFAIK) to
> express a typical access situation on many trunks but also some primaries
> (motorway like access), so that trunk (motorway like physical construction)
> and access could be tagged orthogonally. There are also some trunks that
> permit slower traffic in Germany.
>
> Cheers Martin
>
>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

>> This info is probably worth recording,
>> but legal status should go into a separate tag.
>>
> Legal status of roads in the US isn't quite as clearcut as it is in the UK,
> where the highway=* tag is literally equal to that country's legal
> classification, plus private roads with significant public passage and/or
> reach.
> ...
> At an absolute minimum, we really need to establish values lower than
> tertiary yet above unclassified, and we definitely do need to make the
> freeway/expressway distinction.

I agree that adding expressway=yes tags to more roads is a good idea.
It might be useful for rendering and routing in some situations.

If we allow highway=trunk to be used for all major highways (not only
those that have certain physical charateristics) this give us an
additional level to work with: in the UK and Spain, highway=primary
links smaller towns and villages since all the major highways are
highway=trunk, which leaves highway=secondary for pretty minor roads
("B Class" in the UK) linking villages and hamlets, while
highway=tertiary is for quite minor roads to hamlets or small
neighborhoods, and "highway=unclassified" is usually for tiny public
roads connecting farms or individual, isolated houses out in the
countryside

In the USA, most US highways can be highway=trunk or highway=primary,
most State highways are highway=primary or =secondary, and country or
local roads are highway=secondary or highway=tertiary if they are
significant. I use highway=unclassified for very small roads.

I don't know Alaska well, but I suspect that the one-lane, gravel
borough roads should not be highway=unclassified: they would usually
be highway=secondary or highway=tertiary, like most county roads in
the western USA. If they are the main route to the largest small town
within 100 miles, they might be highway=primary.

Here in eastern Indonesia, most of my highway=primary roads have large
sections of gravel, and most highway=secondary are narrow gravel or
dirt roads (though in Java and Bali they will usually be paved).

- Joseph Eisenberg

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

> Being able to speak each country's highway lingua franca would make it a lot 
> easier for OSM to become the Rosetta Stone of maps simply from ease of 
> classification.

That would mean using "jalan=provinsi" instead of "highway=primary" in
Indonesia, so any global map service (like opencyclemap.org) would
need to interpret all these tags from different languages. If you
limit this to just official languages there would be several hundred
to translate, but there are over 1500 languages with a written
language currently: I don't see why we would limit things to just
official languages.

The main feature tags are in British English and they should be
translated to the appropriate local context by local mappers in each
area, rather than creating new feature tags for every country and
language, so that global maps and routing applications can continue to
work.

It's also helpful that mappers in Germany and Japan can help map my
area here in Indonesia, adding rivers, lakes and roads based on aerial
imagery. They would have trouble if they needed to learn the hundreds
of local languages in each part of Indonesia to tag things properly.

-Joseph Eisenberg

On 12/21/19, Paul Johnson  wrote:
> On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny 
> wrote:
>
>>
>> 20 Dec 2019, 01:25 by ba...@ursamundi.org:
>>
>> So, for example, in the US, instead of motorway, trunk, primary,
>> secondary, tertiary, perhaps something more like freeway, expressway,
>> major/minor_principal (just having this would fix a *lot* of problems
>> with
>> Texas and Missouri and their extensive secondary systems),
>> major/minor_collector...the US just has a way more complex view of how
>> highways work.
>>
>> Or at least some more serious consideration given to the proposal at
>> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS (but perhaps
>> with "other principal arterials" as primary and a new
>> "highway=quartinary".
>>
>> Fitting thing like road classification
>> into UK system is irritating at times.
>>
>> But idea of each country with separate tags
>> for roads is simply a bad idea.
>>
>
> Could you expand on this?  Being able to speak each country's highway
> lingua franca would make it a lot easier for OSM to become the Rosetta
> Stone of maps simply from ease of classification.
>
>
>> This info is probably worth recording,
>> but legal status should go into a separate tag.
>>
>
> Legal status of roads in the US isn't quite as clearcut as it is in the UK,
> where the highway=* tag is literally equal to that country's legal
> classification, plus private roads with significant public passage and/or
> reach.  Off the top of my head we have 1 country, 2 states, 34 tribes, 77
> counties and 597 towns, plus MacQuarie Group Australia running the
> turnpikes and the Boy Scouts of America, Phillips 66, ConocoPhillips, or
> some combination of the three, and potentially scores more private
> entities, operating extensive networks of publicly accessible roads and
> highways in Oklahoma.  And I generally consider myself lucky I have it
> *this* straightforward in the US.
>
> Texas likely has similar situations but throw in the fact that they have 7
> different state highway systems before you get into at least 3 more
> (regional? state? private? unclear...) competing turnpike networks,
> sometimes running side by side on the same right of way (consider TX 121
> with the George Bush Turnpike operated by the North Texas Transportation
> Agency running down the median).
>
> Simply starting with the HFCS and expanding from that (particularly on the
> freeway/expressway distinction, and having more levels between secondary
> and unclassified) would be a fantastic boon to dealing with this mess in a
> more concise fashion as it changes highway=* tagging from almost entirely
> subjective to subjective but within a limited range.  Establish wiki pages
> describing how each region works and let the consumers sort it out from
> there.
>
> At an absolute minimum, we really need to establish values lower than
> tertiary yet above unclassified, and we definitely do need to make the
> freeway/expressway distinction.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Trunk VS primary,

[Joseph Eisenberg]

Above it was said that the highway=trunk vs highway=primary
distinction is mostly for routing applications. But allowing a proper
rendering is also a main goal of the road tagging system.

While it's true that road class is useful for routing when there are
two alterate routes, a main reason to tag highways with a certain
class is to be able to render maps properly at different zoom levels.

When you are making a high-scale, low-zoom-level map of a large area
(say, the whole State of Alaska, all of England, or all of Australia),
you will want to only render highway=motorway + highway=trunk, because
showing all highway=primary would lead to rendering many smaller roads
which are not reasonable to show at that scale in most places.

In England, where these tags were developed, the distinction between
highway=trunk and highway=primary is subtle: both are "A" roads in the
official classification system, but highway=trunk has a special
sub-classification which says they are more important than other "A"
roads (tagged as primary): "UK OSM users follow the practice that all
green-signed A routes (ie primary routes) are tagged highway=trunk,
while black-and-white-signed A-roads (ie non-primary routes) are
tagged highway=primary".

Thus in the USA it's reasonable to use highway=primary for most State
and some US highways, while the most significant ones which connect
cities and large towns would be tagged highway=trunk.

Look at England at z7 on the Openstreetmap-carto style (the highest
level where highway=primary is not shown):
https://www.openstreetmap.org/#map=8/52.017/-0.261

The highway=trunk roads shown here are the main routes between cities
and towns. Zooming in to z8 shows a dense network of highway=primary
roads connecting smaller towns and large villages to towns and cities,
which would not be reasonable to show at z7

Unfortunately, the road classification system in parts of Continental
Europe was different, so mappers in some major countries, including
Germany and France, chose to use highway=trunk as synonym for
"motorroad" (somewhat similar to a U.S.A. "expressway"), with other
major roads tagged as highway=primary. If you look around the
Openstreetmap-carto rendering of Europ at z7, you will see many gaps
in the rendered road network in these countries and surrounding areas
that use the same system.

Compare Spain and Romania, which instead use highway=trunk for all major non-
motorway roads between cities: here the country-wide road network is
clearly visible with showing just highway=trunk and highway=motorway
at z6 and z7.

In the USA, it's fine to limit highway=trunk to expressways in eastern
States where all the important US highways are expressways and these
form a dense network connecting all cities and towns. But in
sparsely-populated Western states even some of the Interstate highways
are not fully motorways, and almost all US highways are just 2 lanes
(one each way) in the area between the Cascades and the Rocky
Mountains, even those that are the main cross-State routes. If we
don't tag these highways as highway=trunk it isn't possible to render
this area in a reasonable way while using the same rendering rules for
the whole USA.

Major US and State highways between cities, like AK-2 and CA-199,
CA-299, US 97 (main route in Eastern Oregon) and US 101 should be
tagged as more significant than a tiny State road in Delaware which
only connects small towns and villages.

I would suggest looking at the Indonesian road tagging guidelines
(which I was not involved in developing, but I use in mapping
locally): they show very different road quality between the developed
areas and the remote parts of the country:
https://wiki.openstreetmap.org/wiki/Indonesian_Tagging_Guidelines#Examples_of_road_class_in_several_provinces_in_Indonesia.
Most trunk roads are only 1 lane each way, but they are still the
main, National road connecting the large cities on each island. This
should be expected in other large countries like the USA, Australia
and Canada.

For tagging the status of a road as a "motorroad" or "expressway" I
would recommend using the tags motorroad=yes and expressway=yes,
rather than tagging all expressways and motorroads as highway=trunk no
matter their classification or significance in the road network. And
adding maxspeed=, surface=, lanes= and access=  will allow routing
applications and specialized renderers to treat these roads properly.

Joseph Eisenberg

On 12/21/19, Graeme Fitzpatrick  wrote:
> On Sat, 21 Dec 2019 at 08:53, Paul Allen  wrote:
>
>> On Fri, 20 Dec 2019 at 22:05, Graeme Fitzpatrick 
>> wrote:
>>
>>>
>>> But would they still count as either =trunk or =primary?
>>>
>>> While they're of high local importance, they're definitely not
>>> high-performance & they don't link major population c

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

Alaska is not attached to the rest of the USA, so consistency with the
Yukon Territory and British Columbia is equally important.

In the western USA, highway=trunk is not limited to expressways like it is
in Germany and France

On the West Coast, several important State highways are tagged as trunks
even though they are not full expressways, because they are the main road
for a large region. For example, see US 199, US 101, CA 99 and CA 299 on
this map of far Northern California:

https://www.openstreetmap.org/#map=7/40.681/-123.184

Expressways should be tagged with additional details like lanes=, surface,
maxspeed=, expressway=yes, and motorroad=yes

The latter two tags could be useful for rendering if they were applied
consistently.

- Joseph Eisenberg

On Tue, Dec 17, 2019 at 8:29 AM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:26 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Trunks are rarely expressways in remote parts of the world. In Britain,
>> where this tag started, many highway=trunk roads are not expressways or
>> motorroads.
>>
>
> Are we not trying to remain internally consistent with the rest of the US?
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

Trunks are rarely expressways in remote parts of the world. In Britain,
where this tag started, many highway=trunk roads are not expressways or
motorroads.

Joseph

On Tue, Dec 17, 2019 at 8:22 AM Paul Johnson  wrote:

>
>
> On Mon, Dec 16, 2019 at 6:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> I would use highway=trunk the whole way for consistency. In Canada the
>> connecting highway is also highway=trunk. This makes sense because AK 2 is
>> linking Fairbanks, the largest city in this part of Alaska, with All the
>> cities in Canada and the lower 48 States.
>>
>
> That's kind of my thinking as to why it should be primary instead of
> secondary (as typical for the US for state highways).  Almost all of it's
> not even paved, it'd be a hard stretch to call it an expressway (trunk).
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Joseph Eisenberg]

I would use highway=trunk the whole way for consistency. In Canada the
connecting highway is also highway=trunk. This makes sense because AK 2 is
linking Fairbanks, the largest city in this part of Alaska, with All the
cities in Canada and the lower 48 States.

-Joseph

On Tue, Dec 17, 2019 at 7:37 AM Eric H. Christensen via Talk-us <
talk-us@openstreetmap.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I've noticed that there is some mixed tagging of the Alaska Highway AK-2
> from the Canadian border through Delta Junction to where it becomes a
> divided highway just south and east of Fairbanks at Eielson Air Force
> Base.  Some of the non-divided portions are tagged as trunk while the other
> (majority) is tagged as primary.  The definitions of these two tags are
> similar enough in the U.S. to almost be interchangeable.  Being that this
> highway links many villages with Canada and the City of Fairbanks and the
> speed limit is 65 MPH, I would lean towards this highway being tagged as
> trunk.  By the same definition, I'd probably argue the same for the Richardson
> Highway AK-4
> 
> .
>
> Thoughts?
>
> R,
> Eric "Sparks"
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: ProtonMail
>
> wsFcBAEBCAAGBQJd+BStAAoJEIB2q94CS7PR7d4QAMWWtHe8EB3ALRrczWY/
> f3kpdRyYqP8QYVvc1vdvu+j/hAP8NdFGb+aDLx2YLMerDEu4Lt7B0BMN78vT
> LD5629ujwkViIpv8AQt97iWLlruEZOczn44Yhr7KIV6itzmmd9VXfXMs8Kzj
> gOVFdmABwgJd3S/7/tDavgsM49Bh1nvYHkzdUdBwoZ9MuCQbFpoIdj2EPc/W
> Z/XDDssBUcxDIzWaa8kDWB/FlizE+5v6QkgULiB4c7grEbg/7fNziisdYAWp
> lwAqkirEFLsYInrtc80bfkHX0pgb8AtFFZnyDyrY3ijU23Y2Qz5o1qn+4jbS
> PwFCgO6z771vGw3J+RCmKuhOG3fjyW//X0OmtUkAPdiSWKNsPabLlG4/FWib
> phl+2IDx0wlHqYITBEGRGw6pq96chIinlHzdWNmC82/fGI0IXo1Ic9/r3S2v
> Uzr8bwATdLl6mRhYZjAvcLg8yHKblG0PvINjwN4exAthSi+qGsoM5bYDBi8V
> sccUBA0pypUPWCnOVtck4EmMdIJ63b++EoKQ0DUNMGDkpaac6ErKOXDdVt97
> ySbzNzfkkAyproGrwmDLeVQ8gt8aoc0vjlQUZpOoKDcuXgZ7mIhWmwn+4kLL
> WTYYuZn02MVoAsdfbfPB3IyNy9eqmadymFlyNL8AfJC69/0S1TAGLtQFoJjv
> wQlY
> =oEIv
> -END PGP SIGNATURE-
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Oahu, Hawaii CDP boundaries

[Joseph Eisenberg]

ZIP Codes (US Postal Service codes) are not administrative boundaries.
They are widely used for addressing, for routing and for deliveries by
private companies in addition to the USPS, but they are not used for
any official administrative purposes, at least not in the States where
I have lived.

On 9/7/19, Mateusz Konieczny  wrote:
>
>
>
> 6 Sep 2019, 22:10 by stevea...@softworkers.com:
>
>> I slightly disagree with Mateusz that we "reflect local postal"
>> boundaries, as we don't do that in the USA with ZIP codes:  they are
>> routing algorithms, not actual areas definable by a (multi)polygon.
>>
> Note that I was asking whatever it is
> actually administrative boundary
> (Postal codes are not forming
> administrative boundaries in Poland,
> not sure is it different in USA)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

To be prescriptive, the best way is to make a proposal, discuss it,
and vote on it.

While this is usually done on the international Tagging mailing list,
I've seen that the Japanese community has done formal proposals to
discuss how a tag should be used in Japan specifically.

We could consider something like that if we want to suggest a better
way to define highway=trunk in the USA, especially since this tag is
used several different ways, in different countries currently.

-Joseph

On 8/30/19, stevea  wrote:
> On August 29, 2019 at 8:08:08 AM PDT, Bradley White
>  wrote:
>> I'm on the same page with Steve that describing how tagging currently *is*
>> used and
>> debating over how tagging might be better used, should be kept separate.
>
> Kind of you to say so.  I (and others) often find it useful to distinguish
> these as "descriptive" (how tagging IS used/done) vs. "prescriptive" (how
> tagging SHOULD BE used/done).  Sometimes in the wiki, sometimes in talk.
>
> Often, it is helpful to be DEscriptive, as in "this is what we do (now)."
> Much less often, and best when this is made quite clear, it MIGHT be helpful
> to be PREscriptive, though let's be careful how we "prescribe" how "this is
> how it ought to be."
>
> SteveA
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

"As it stands, I will continue to use 'trunk' on any section of highway
that is somewhere between a freeway and a conventional 2-lane highway
per US consensus. Hopefully one of these days consensus will shift."

It sounds like there isn't a consensus, per comments on Hwy 101: "I
did this a year or two ago, then changed it back following the
previous time this discussion came up last year. Someone else has
recently changed it back to trunk in its entirety as you describe".

Sound like we don't have a consensus, which isn't surprising. The USA
has more similarities to Europe as a whole, considering the diversity
of environments and different legal systems and traditions between
states, especially if we remember Alaska and Hawaii.

I live in Indonesia currently, and here the "national roads" are
supposed to be tagged as highway=trunk. In Java they are all pretty
major highways, usually 4 lanes, though not limited-access. Sometimes
they are just 2 lanes. But here in eastern Indonesia, many of the
trunk roads are not yet paved.

That's probably not relevant for anywhere in the USA (even in Alaska
the main highways between cities are paved... right?) but it's a
reminder that we can certainly choose to do things in a way that makes
sense for mapping the USA; we don't have to use the British or German
standards.

On 8/29/19, Bradley White  wrote:
>> For example, US Hwy 101 is the main route connecting the cities (e.g.
>> Eureka) and towns along the coast of northern California. Right now
>> only some segments are tagged as highway=trunk. I would like to
>> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
>> leaves 101 and heads to I-5, at Crescent City.
>
> I did this a year or two ago, then changed it back following the
> previous time this discussion came up last year. Someone else has
> recently changed it back to trunk in its entirety as you describe (as
> well as US 395, CA 70); I explained in a changeset comment that the
> "major intercity highway where no motorway exists" definition (per
> Highway:International_equivalence) is contentious and not commonly
> used, but that I have no plans on reverting their changes.
>
> Caltrans doesn't appear to have "divided" as a requirement for an
> expressway build, or even necessarily a freeway (See:(California)
> State Highway Map 2005; David Rumsey Map Collection) - these terms are
> used to describe the level of access control on a given highway. US
> 101 through Redwood Ntl Park is signed with "Freeway Entrance" and is
> fully access controlled, but is an undivided 4-lane road. Many 2-lane,
> undivided roads are considered expressways in California, for example:
>
> - Vasco Road connecting Antioch & Livermore
> - Portions of CA 4 west of Angels Camp
> - CA 108 east of Sonora (fully access controlled 2-lane road)
>
> Once you know what to look for - reduced access to adjacent
> properties, smoothed road geometry (esp. when bypassing old highways),
> hard shoulders, usually 65 mph - they aren't too hard to differentiate
> from conventional 2-lane highways with no access control. Where these
> are obvious I generally tag them as trunk roads as opposed to primary.
> Specifically in the case of CA 108, I reject that a fully access
> controlled two-lane road is anything less than a trunk, if we have
> decided to use 'trunk' to mean 'expressway'. California doesn't use
> AASHTO definitions so I won't either.
>
> Reno, NV has a couple urban arteries that straddle the divide between
> trunk and primary (specifically: McCarran Blvd/NV 659, Pyramid Hwy/NV
> 445 north of McCarran, Veterans Pkwy, foothills portion of Mt. Rose
> Hwy/NV 431). These roads carry traffic at speeds higher than other
> nearby arteries (45-55 mph as opposed to 40 mph). They are built to
> the highest level of access control specified by Washoe RTC -
> generally no direct access to properties, except for retail/commercial
> areas (where access is quite frequent), or rural areas where no other
> roads provide access to properties. They range from undivided w/
> center turn lane to divided with concrete jersey barriers & headlight
> blinders (similar to a freeway). The majority of these roadways have
> bike lanes, and many have sidewalks. They are quite similar to San
> Jose's expressway system, except for a lack of grade-separated
> interchanges. Are these primary, or trunk? I don't really know. They
> currently sit at an awkward mix of trunk and primary depending on how
> definitively myself and others think they are "expressways" or not.
>
> I don't deny that "divided highway with partial control of access" is
> a rigorous definition, with which it is certainly possible to tag
> unambiguously with. I just question whether it is a good choice in the
> US to use 'trunk' to mean 'expressway' in the same way that 'motorway'
> means 'freeway', when the US has a formal freeway system, but lacks a
> formal expressway system. Most other countries that also lack a formal
> expressway system

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

I checked and motorroad=yes in used in Spain for "Autovias" which are
like expressways, but they usually allow bicycles, just like many
expressways in the USA.

So the idea that motorroads prohibit bicycles and pedestrians is more
specific to France, Germany and some other countries, while in other
places the tag is more like the USA-specific expressway=* - a divided
highway with somewhat limited access, higher speeds, prioritizing
motor vehicle travel but not necessarily prohibiting bikes.

> I think it'd honestly be easier to get everyone to agree that it's time for 
> lanes=* to include all lanes, not just lanes of a minimum width accessible to 
> a pretty narrow selection of vehicles...

I don't quite understand this comment. Is it about bike lanes?

Are we sure that highway=trunk actually has a clear definition in
North America? It seems to be used differently in several places I've
checked; eg. California vs East Coast vs North Dakota.

On 8/29/19, Paul Johnson  wrote:
> On Wed, Aug 28, 2019 at 9:05 PM Joseph Eisenberg
> 
> wrote:
>
>> I don't have any local knowledge about old route 66 in OK, but I'd
>> like to address the use of highway=trunk in general.
>>
>> I'm in favor of using a secondary tags like motorroad=yes and
>> expressway=yes, along with other details like lanes=, surface=,
>> maxspeed=, etc, to specify expressways, rather than using
>> highway=trunk for this.
>>
>
> Ideally I'd prefer we started using tags that actually reflect what people
> call things in this country and have a lookup table on the wiki someplace
> for national equivalence, ie, highway=expressway, highway=freeway, etc,
> since the US tends to have more levels and nuance than the relatively easy
> "A/B/C/M/U" grading the British have officially that carries over there.
> We don't really have motorroad as a well defined thing here, either, even
> about 3/5ths of the states allow pedestrians and bicycles on most
> freeways.  Using trunks for expressways does give a pretty well defined
> expectation of what you're going to be experiencing as it's used now.
>
> Like the distinctions between primary/secondary/tertiary, trunk was
>> originally intended to describe the role of a road in the network.
>> While most trunk highways are divided and have more than 1 lane in
>> each direction in densely-populated areas, it's quite normal for to
>> have narrower roads as the main route between 2 cities, in
>> sparsely-populated parts of the country.
>>
>
> Well, literally the official designation of the highway, before the project
> jumped outside the UK.
>
>
>> For example, US Hwy 101 is the main route connecting the cities (e.g.
>> Eureka) and towns along the coast of northern California. Right now
>> only some segments are tagged as highway=trunk. I would like to
>> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
>> leaves 101 and heads to I-5, at Crescent City.
>>
>
> I'm not sure that's really worth revisiting so much; seems for the US as we
> have it now.  NE2 nationally torque-tagged everything in network=US:US as
> trunk and that seems to have broken the already established trunk.
>
>
>> The segments that are divided and wider can be tagged expressway=yes,
>> lanes=4, maxspeed=, etc, so if people want to render these differently
>> they can (routers are probably more interested in the number of
>> intersections, traffic signals, lanes, maxspeed, and surface, so the
>> expressway=* tag isn't really needed).
>>
>
> I think it'd honestly be easier to get everyone to agree that it's time for
> lanes=* to include all lanes, not just lanes of a minimum width accessible
> to a pretty narrow selection of vehicles than redefine highway=trunk in
> North America at this point.  Certainly a lot less subjective.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

I don't have any local knowledge about old route 66 in OK, but I'd
like to address the use of highway=trunk in general.

I'm in favor of using a secondary tags like motorroad=yes and
expressway=yes, along with other details like lanes=, surface=,
maxspeed=, etc, to specify expressways, rather than using
highway=trunk for this.

Like the distinctions between primary/secondary/tertiary, trunk was
originally intended to describe the role of a road in the network.
While most trunk highways are divided and have more than 1 lane in
each direction in densely-populated areas, it's quite normal for to
have narrower roads as the main route between 2 cities, in
sparsely-populated parts of the country.

For example, US Hwy 101 is the main route connecting the cities (e.g.
Eureka) and towns along the coast of northern California. Right now
only some segments are tagged as highway=trunk. I would like to
upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
leaves 101 and heads to I-5, at Crescent City.

The segments that are divided and wider can be tagged expressway=yes,
lanes=4, maxspeed=, etc, so if people want to render these differently
they can (routers are probably more interested in the number of
intersections, traffic signals, lanes, maxspeed, and surface, so the
expressway=* tag isn't really needed).

On 8/29/19, Paul Johnson  wrote:
> On Wed, Aug 28, 2019 at 7:04 AM stevea  wrote:
>
>> Hi Paul, Hi Volker, Hi talk-us:
>>
>> The topic begs the question as to what such (usually very) old,
>> poor-condition (where they ARE poor) roads should be tagged (we limit
>> ourselves to US roads here because this is talk-us), and at what
>> granularity.  (Volker COULD do detailed tagging, but I hear loud and
>> clear
>> he prefers high-granularity tagging, as do I, though we all recognize how
>> tedious this can be).  And "old 66" is a quintessential example, many
>> segments are a century old or older:  it is known as "the Mother road" by
>> many.  BTW, many public agencies under the umbrella of Southern
>> California
>> Association of Governments are working on developing USBR 66 in
>> California
>> for cyclists (the route number choice is no coincidence as some
>> alignments
>> follow the old Mother road).  This was actually in OSM as an early
>> proposed
>> route, but was removed to conform to USBRS proposed route conventions.
>> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
>> will re-enter these data.  It makes sense to pay close attention to the
>> underlying infrastructure tagging (tertiary, surface, smoothness...) as
>> we
>> do so since these are important to cyclists.
>>
>
> So, the segment in question given in the example to me (I don't think the
> response was intended only for me, so I'm not quoting the whole thing) is
> https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
> from November 2018 on it at
> https://openstreetcam.org/details/1305935/3747/track-info, showing it's a
> pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
> slowing towards its eastern end, and is currently a part of OK 66.
>
> I think a better argument for downgrading from trunk exists in Southern
> California if it hasn't been downgraded already.  There's some decent
> chunks east of Indio in San Bernardino County off the top of my head that
> were clearly constructed as trunks, have since left Caltrans inventory and
> are now county roads, and SB County has just let one side of the road rot
> off, running both directions undivided on the other (usually the former
> westbound-only carriageway, from memory, as last I drove it I was going
> eastbound, the center divider was on my right, and it looked like the other
> side hadn't been usable for at least a decade with weeds and huge cracks
> growing out of the abandoned carriageway).
>
> A case can be made for highway=trunk (for connectivity reasons) yet I do
>> resonate with "secondary at best" for such old, poor roads.  Tagging
>> highway=trunk is about as high a classification as the very best portions
>> of this road will ever get, and only on its highest-speed segments which
>> are divided.  This implies highway=tertiary (MAYBE secondary) where the
>> road is NOT dual carriageway, as highway=trunk in the USA means "with a
>> barrier or median separating each direction of traffic" (truly dual
>> carriageway).  Yes, it is appropriate to tag highway=secondary on some
>> segments, I believe these to be in the minority compared to tertiary
>> (which
>> likely makes up the majority of what remains of this route in many
>> states).
>>
>
> I could see secondary or tertiary for the non-expressway portions (though
> most of it is state highway, so that would be secondary at lowest for the
> parts that are currently part of state highways).  But it does have among
> the longest portions of still-extant expressway portions, mostly still in
> the state highway inventory here in Oklahoma.
>
>
>> I also say including 

Re: [Talk-us] What is the meaning of hgv:national_network=yes/terminal_access?

[Joseph Eisenberg]

Thank you, that suggests that the apparent increase in usage since
2012 is due to splitting existing ways. I'll mention this on the wiki
page, since it's not something you can see in the Taginfo numbers.

On 8/6/19, Paul Norman via Talk-us  wrote:
> On 2019-08-04 7:56 a.m., Joseph Eisenberg wrote:
>> I've found this undocumented tag, used 130,000 times, almost
>> exclusively in the USA.
>>
>> https://taginfo.openstreetmap.org/keys/hgv%3Anational_network#overview
>>
>> Values: yes 86.56%   terminal_access 13.37%
>>
>> I thought it might be imported from Tiger, but the usage has increased
>> gradually since 2012: 60k more ways have been tagged in that time.
>
> If you look at the length, it increased to 10 km in Nov 2011, and to
> 132000 km in Nov 2012. Aside from those sudden increases, there has been
> no change in usage.
>
>> How are these tags being used?
>
> They're not.
>
>> I'm guessing that hgv:national_network=yes means that a road is
>> designated for heavy trucks to use for long-distance trips.
>
> It means that it has a particular designation for budget purposes with a
> department of the federal government.
>
> If I'm recalling correctly, these tags were invented by NE2 and never
> subject to any discussion, no data consumers use them, and they are
> poorly documented.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] What is the meaning of hgv:national_network=yes/terminal_access?

[Joseph Eisenberg]

hgv:national_network=terminal_access means > "a road which can carry
cargo trucks and has an adequate turn-around facility at the end"

Great, that's helpful. So it sounds like this tag is a synonym for
hgv=destination or hgv=yes?

Joseph

On 8/5/19, Mike N  wrote:
> Hi, "Terminal Access" appears to be unique to California, and generally
> means a road which can carry cargo trucks and has an adequate
> turn-around facility at the end.   They most often provide access for
> cargo pick-up or delivery.   (at least one area says it does not include
> oversize trucks)
>
>Regards,
>
>Mike Nice
>
> On 8/5/2019 6:33 AM, Joseph Eisenberg wrote:
>> Ok, thanks! I've created a wiki page at Key:hgv:national_network
>>
>> It's still not clear to me what the tag
>> hgv:national_network=terminal_access means - please add if you can
>> tell from the data in your area, perhaps?
>>
>> Joseph
>>
>> On Mon, Aug 5, 2019 at 1:13 AM Mike N  wrote:
>>>
>>>
>>> This was part of the iterative road improvement after TIGER as we began
>>> with major highways.?? ?? I believe it came from the public domain
>>> information for the National Network
>>> https://ops.fhwa.dot.gov/freight/infrastructure/national_network.htm .
>>>
>>> On 8/4/2019 10:56 AM, Joseph Eisenberg wrote:
>>>> I've found this undocumented tag, used 130,000 times, almost
>>>> exclusively in the USA.
>>>>
>>>> https://taginfo.openstreetmap.org/keys/hgv%3Anational_network#overview
>>>>
>>>> Values: yes 86.56%?? ??terminal_access 13.37%
>>>>
>>>> I thought it might be imported from Tiger, but the usage has increased
>>>> gradually since 2012: 60k more ways have been tagged in that time.
>>>>
>>>> How are these tags being used?
>>>>
>>>> I'm guessing that hgv:national_network=yes means that a road is
>>>> designated for heavy trucks to use for long-distance trips.
>>>>
>>>> Perhaps hgv:national_network=terminal_access means that heavy trucks
>>>> can only use a road if their destination is on it, or near it?
>>>>
>>>> ___
>>>> Talk-us mailing list
>>>> Talk-us@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>>
>>>
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] What is the meaning of hgv:national_network=yes/terminal_access?

[Joseph Eisenberg]

I've found this undocumented tag, used 130,000 times, almost
exclusively in the USA.

https://taginfo.openstreetmap.org/keys/hgv%3Anational_network#overview

Values: yes 86.56%   terminal_access 13.37%

I thought it might be imported from Tiger, but the usage has increased
gradually since 2012: 60k more ways have been tagged in that time.

How are these tags being used?

I'm guessing that hgv:national_network=yes means that a road is
designated for heavy trucks to use for long-distance trips.

Perhaps hgv:national_network=terminal_access means that heavy trucks
can only use a road if their destination is on it, or near it?

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Joseph Eisenberg]

I would recommend starting to use boundary=protected_area for State
parks, and other parks that are large natural areas that are designed
for a balance of tourism and protection of the natural environment but
are not actually National Parks.

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

You can tag state parks like this:

boundary=protected_area + protect_class=2 + protection_title="State Park"

Protect Class 2 is the same type as National Parks, and will be
rendered and interpreted the same by most database users, but the
protection title makes it clear that it's actually a State Park, not a
National Park.

For county parks: many of these are small parks that are similar to a
usual urban park, with gardens, playgrounds, sports fields etc, and
can be tagged with leisure=park. Others are natural areas or nature
reserves, and could use boundary=protected_area + protect_class=5 +
protection_title="County Park".

State and National Forests, which are used for logging and grazing as
well as recreation, can be tagged as:
boundary=protected_area + protect_class=6 + protection_title="National
Forest" or "State Forest".

These features will all be rendered the same as boundary=national_park
and leisure=nature_reserve in many renderings styles, but it's nice to
be a little more specific.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Joseph Eisenberg]

On 4/29/19, Greg Troxel  wrote:

> With leisure=nature_reserve, leisure=park, golf courses, cemetaries,
> schools, etc., we represent them on the map by some kind of shading or
> fill.  But, boundary=protected_area is represented by denoting the
> border, and this does not serve map users well.

If you are talking about the Openstreetmap-carto style (the standard
map layer on openstreetmap.org), then this is not quite correct.

It's true that leisure=park and golf courses are represented by a fill
color for the whole polygon.

However, leisure=natural_reserve, boundary=national_park and
boundary_protected area (with protect_class  1 thru 7 and 97-99) are
currently rendered identically, with a green semi-transparent outline.
(There is also a semi-transparent green fill at low zoom levels).

The other type of boundary is "boundary=aboriginal_lands" and
"boundary = 'protected_area" with "protect_class=24" - these are used
for American Indian and Alaskan Native reservations and other similar
features, and are
rendered with a brown outline.

Military areas and tourist areas (zoos, theme parks) are also rendered
with outlines in red and purple.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] trail tagging

[Joseph Eisenberg]

> I think it makes no sense to call a dirt path, open to more than 1 user 
> group, anything other than a path

It is very common to tag dirt footpaths as highway=footway in most
parts of the world, if the path is designed for and used by people on
foot.

For example, here in Indonesia there are never signs that say you
can't ride a bicycle on the highway=footway that connect mountain
villages, but they are certainly not designed for bicycles and would
be extremely technically challenging on a MTB. Horses are not
prohibited either, but there are no horses in the area. So I map these
paths as highway=footway

In the USA I would think it reasonable to use highway=footway for dirt
single-track trails designed for travel on foot, even if bicycles or
horses are not specifically prohibited.

I would use highway=path for MUPs (multi-use paths) that are
specifically designed for use by both people on bikes and people
walking or riding horses, along with the appropriate access tags.

Also, I don't think this page is authoritative:
https://wiki.openstreetmap.org/wiki/United_States_roads_tagging
Note at the top is says "There is conflicting information on this
topic at several places. Please see Talk:Highway tag usage and the
Talk-US Mailing List for discussion."

On 4/19/19, brad  wrote:
> Everywhere I've been in the US or Canada a dirt 'way' too narrow for a 4
> wheel vehicle is called a trail, path, or single track.   For the most
> part they are appropriately (IMO) tagged as path. Unfortunately the wiki
> says this for highway:path (the highlighting is mine):
>
> /A non-specific path. //*Use **highway=footway
> **for paths
> mainly for walkers, **highway=cycleway
> **for one
> also usable by cyclists, **highway=bridleway
> **for ones
> available to horse riders as well as walkers *//and //highway=track
> //for ones
> which is passable by agriculture or similar vehicles./
>
> I think it makes no sense to call a dirt path, open to more than 1 user
> group, anything other than a path.    Since about 98% of the trail
> tagging that I've seen seems to agree, Is there consensus on this?
> Perhaps if the international group likes the description as is, a
> clarification on the US road tagging wiki page?
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Joseph Eisenberg]

Natural=peak must be a local high point, so it has to be at least a
few meters higher than the surrounding land. A natural=peak does not
have to be the highest point of a mountain, but it has to have some
topographical prominence. Not all spot elevations on USGS are of
peaks, some are just a visually prominent part of a ridge, and other
are saddles.

In October 2018 there was a suggestion to use the value "promontory"
for points that are not peaks, for example a prominent shoulder of a
mountain or the end of a ridge. Thus natural=promontory could work,
along with ele=* and name=* for some of these features.

Wikipedia definition:
https://en.wikipedia.org/wiki/Promontory

Link to previous discussion:
https://lists.openstreetmap.org/pipermail/tagging/2018-October/039659.html

On 3/9/19, Martijn van Exel  wrote:
> Perhaps they should be tagged not as peaks then but as a place node
> (place=locality probably)?
>
>> On Mar 8, 2019, at 10:23 AM, Mike Thompson  wrote:
>>
>>
>>
>> On Fri, Mar 8, 2019 at 6:29 AM Kevin Broderick > > wrote:
>>
>> Would https://www.openstreetmap.org/node/4992960980
>>  be an example of (or very
>> similar to) what you're talking about?
>> Yes, slightly different, but same general concept.
>>
>>
>> I've been told that one is a local reference point ("25 Short", ie. 25
>> feet short of 10k), and at least one article
>> (https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole
>> )
>> backs that up.
>> I have seen back country trip reports mention such points (at least those
>> that are high points), and they have *some* value therefore, but as I
>> suggested earlier, "point n,nnn" is to me more of a description rather
>> than a name in most cases.
>>
>> Mike
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Joseph Eisenberg]

This was discussed at the main Tagging mailing list a couple of months ago:

Start of thread:
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041597.html
Continuation in January:
https://lists.openstreetmap.org/pipermail/tagging/2019-January/041720.html

The wiki page for Motel was updated at that time:
https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dmotel

A number of people said that the name on the sign is the main way to
distinguish a hotel vs a motel, but some thought that the easy access
to no-fee motor vehicle parking from the rooms was also a useful
distinction.


On 3/9/19, Martijn van Exel  wrote:
> I've slept in some pretty nice places that had exterior room access. I
> wouldn't call that out as the only demarcating property. To my mind it's a
> combination of location, amenities and layout / architecture.
>
> Interesting discussion!
>
> Martijn van Exel
>
>> On Mar 8, 2019, at 18:03, Tod Fitch  wrote:
>>
>> For me the difference is interior hallway to access room (hotel) vs
>> exterior access to each room (motel).
>>
>>
>>> On March 8, 2019 4:47:33 PM PST, Peter Dobratz  wrote:
>>> How do you distinguish between the tourism=hotel and tourism=motel tags?
>>>
>>> The criteria that I was imagining is that a motel is a single story
>>> building where you have the ability to park you car directly outside of
>>> your room. A hotel would be other types of buildings such as multi-story
>>> where most guests cannot park directly outside their room.
>>>
>>> There's the curious case of the two Motel 6 facilities directly across
>>> the road from each other.  I had marked these as tourism=hotel based on
>>> the building architecture, but maybe all Motel 6's should be
>>> tourism=motel?
>>>
>>> https://www.openstreetmap.org/note/1645570
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> Peter
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NC sidewalk data import

[Joseph Eisenberg]

The sidewalk style is somewhat controversial. For routing applications, it
is simpler if the sidewalk is added as a tag on the highway. This also
makes it easier to render clean-looking maps. However, some people prefer
to have the sidewalks separately mapped, so that they can be seen at high
zoom levels in rendered maps.

I would suggest checking the current method used in North Carolina,
especially in the cities or towns where you plan to add missing sidewalks.
It’s probably best to continue using the method that local mappers have
chosen. This may vary between different towns.

Thank you for helping make Openstreetmap even better!
On Mon, Jan 28, 2019 at 7:48 PM Rihards  wrote:

> On 27.01.19 21:41, Melanie Mazanec wrote:
> > Hello,
> >
> > I'm a front end dev for a city government working on a side project to
> > fork and add to AccessMap  for North Carolina
> > cities.
> >
> > In order to make this happen, I want to import North Carolina city
> > sidewalk data into OSM.  I have no prior OSM experience, so I'm
> > following the suggested wiki protocol and reaching out here before
> > attempting an import.
> >
> > Does anyone have advice about tutorials or where to start?  Are there
> > any NC OSM communities or enthusiasts I can connect with?  Also, it
> > seems like there are two competing sidewalk data formats.  Is there a
> > preferred standard now?
>
> Hi, that's really great news - welcome to OSM.
> It would be useful if you would try some basic mapping first to get
> familiar with OSM data structure. Try to map something near your
> workplace or home.
> That doesn't stop you from working on the import, of course. Any
> questions on OSM are welcome on the IRC channel #osm (
> https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> communication channel.
>
> > Thanks,
> > Melanie Mazanec--
>  Rihards
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] The San Jose / Santa Clara border

[Joseph Eisenberg]

Do the latest NGS topographical maps show the city limits properly? Those
are public domain
On Sun, Jan 27, 2019 at 10:16 AM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> On Jan 26, 2019, at 4:00 AM, Andy Townsend  wrote:
> > A mapper has recently changed this to "cut the corner off" north of the
> 880 between San Jose airport and Stevens Creek Mall / Westfield Valley
> Fair.  You can see the change at
> http://overpass-api.de/achavi/?changeset=66619223&zoom=18&lat=37.33883&lon=-121.93327&layers=B0TTTFT
> .
> >
> > Some of this mapper's previous changes have had to be undone, so I did
> check the node change made here to see if it might be one of them.
> However, according to the node history
> https://www.openstreetmap.org/node/373647840/history#map=13/37.3600/-121.9066
> the original source of this node was a changeset quite a while ago with a
> description "adjust boundaries based on san jose city map, bing, and common
> sense ".  It therefore would be great if a local could check it if possible.
>
> I'm fairly local (SJC is my "home airport") yet I'm not finding
> easily-available San José City Limit boundaries in an ODbL-compatible
> format which I could use to relatively quickly repair the damage.  (The
> user mk408 has a history of "making it up as he sees fit" OSM data entry
> which many have disputed or redacted, for example, many years ago he made
> MANY roads in the entire South Bay region — Campbell, Los Gatos, Monte
> Sereno, southern San José —into highway=tertiary roads, and that remained
> very questionable until it slowly but surely "healed itself," again, this
> took months-to-years).  There are some geo data at
> http://csj-landzoning.appspot.com/index.html which indicate the present
> OSM data are "largely correct," the exception being that the area directly
> over the northern part of the airport do not include the "leg" that
> "covers" runway 12L/30R and that the acute angle over taxiways V, W and W1
> is more like "aligned with these taxiways, rather than cutting across
> them."  You really have to see them rather than expect that I can describe
> them with text.  They are, again, "mostly correct" but could use some
> rather minor correction.
>
> As I bumped into somebody on a plane on my way back from SOTM-US Seattle
> (2016) who works in the San José City Hall and when she met me was bowled
> over at the coincidence that I was the very person sitting next to her
> drinking gin and tonic who entered into OSM most of Santa Clara County's
> bikeways/bicycle infrastructure and network=lcn routing (which the city
> office found "extremely helpful" — her words), it's conceivable that I
> might be able to use that to sway release of some data which could be
> forthcoming.  While I don't know quite who to call, exactly, if somebody
> wants to "release to me" ODbL-compatible data which need to be harmonized
> with what are now in OSM, I'll volunteer to be the "nexus of citizen entry"
> to assure they find their way into our wonderful map.  Send me a pointer to
> the data, assure me they are ODbL-OK and I'll "merge" these into OSM.
>
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US Bureau of Land Management Boundaries

[Joseph Eisenberg]

This data is no less verifiable than national forest boundaries and federal
wilderness boundaries; these generally need to be checked against official
sources, just as BLM boundaries will.

Municipal boundaries are perhaps even harder to verify than boundaries of
BLM land and National Forests in some States.

But I wonder about using boundary=protected_area and class 27 for BLM land.
While this fits with the wiki definition of “land owned by the
public/government”, it’s odd to include this under protected_area, and it
is not specific.

If you are adding BLM lands that have any specific protection or planned
usage it would be good to try to find more specific classes, when possible.

There was a comment about this on the wiki discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Tag:boundary%3Dprotected_area#Relationship_of_public.2FGovernment_and_protection
On Sun, Jan 6, 2019 at 12:45 PM brad  wrote:

> Ian,
> I want to import this data because I think its important for a complete
> map.   We have national forest, wilderness  and national park boundaries in
> OSM!   This is no different.   If you look at many maps they show all of
> them.
>
> I'd like it to show up on any map that I use.   I'm working on a 'better'
> version for garmin using mkgmap.   I hope it gets rendered with
> OpenAndroMaps too.   I haven't used the onine osm.org map very much.
>
> I am excited to participate and improve OSM and in my opinion this is a
> big gap in the OSM database.   Where I live, we don't use OSM for building
> footprints, we use it to find our way in the national forest, the BLM land
> and the national parks.   It's very useful to know what is public or
> private land.
>
>
> Brad
>
> On 1/5/19 8:19 PM, Ian Dees wrote:
>
> Hi Brad, thanks for proposing this import and posting it here.
>
> I would strongly prefer that we not import boundaries like this into OSM.
> Boundaries of all sorts are almost impossible to verify with OSM's "on the
> ground" rule, but BLM boundaries in particular are such an edge case (they
> have no other analog in the world, really) and almost never have apparent
> markings on the ground to check. Since these boundaries aren't visible,
> this data can never be improved by an OpenStreetMap contributor. The
> boundaries are defined by the government, and any sort of change to them
> would make them diverge from the official source.
>
> But having said that, I'm curious why you wanted to import this data? Did
> you want to have it show up on the osm.org map? Are you trying to build a
> custom map? Or are you excited to participate and improve OSM? If it's the
> latter, there's lots of other data that is a better fit to import into OSM:
> address points and building footprints come to mind, for example.
>
> -Ian
>
> On Sat, Jan 5, 2019 at 9:03 PM brad  wrote:
>
>> I'd like to import BLM (US Bureau of Land Management) boundaries into
>> OSM.This is not an automated import as you can see from my workflow.
>>
>> Workflow:
>> Download shape file from PADUS (1 state at a time):
>> https://gapanalysis.usgs.gov/padus/data/download/
>> Load into Qgis and filter for BLM boundaries
>> Clean up as necessary (there are some extraneous ways at state
>> boundaries & elsewhere)
>>
>> Convert to OSM with ogr2osm and the following tags
>>  tags.update({'type':'boundary'})
>>  tags.update({'boundary':'protected_area'})
>>  tags.update({'operator':'BLM'})
>>  tags.update({'ownership':'national'})
>>  tags.update({'protect_class':'27'})
>>  tags.update({'source':'US BLM'})
>>  use the shapefile attribute 'Unit_Nm' as the name
>>
>> Import with JOSM
>>
>> The San Luis unit (CO) is here for your inspection.
>> https://www.dropbox.com/s/qxv5gny2396ewki/sanLuisBLM.osm?dl=0
>>
>> Comments?
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Wilderness in National Forest?

[Joseph Eisenberg]

I've noticed that federal Wilderness areas in Northern California and
Southern Oregon are mapped as if they are not part of the surrounding
national forest(s).

Is this correct mapping? On older USGS maps the Wilderness areas were
always shown as being enclosed by the surrounding National Forest (or
other Federal lands).

From Wikipedia:
"Wilderness areas are parts of national parks, wildlife refuges,
national forests, and BLM lands; some units managed by different
agencies. Initially, the NWPS included 34 areas protecting 9.1 million
acres (37,000 km2) in the national forests. ... "
https://en.wikipedia.org/wiki/National_Wilderness_Preservation_System

Also, boundary=protected_area is going to be rendered on the
Openstreetmap-carto style soon. I'd suggest we take a look into adding
boundary=protected_area with protect_class=* as appropriate.

https://github.com/gravitystorm/openstreetmap-carto/pull/3509

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Monterey - Santa Cruz County line in Monterey Bay

[Joseph Eisenberg]

From the Help page, user kurtrad writes:

> "A friend of mine says the Monterey/Santa Cruz county line in openstreets 3 
> miles out to sea that travels from the mouth of the pajaro river to the north 
> south california boundary line is wrong. In openstreetsmap the line travels 
> west, south, west. My friend says the line should travel directly west."

> https://www.openstreetmap.org/#map=11/36.8266/-121.9009

"I have a friend who says the openstreets map county line between
Monterey and Santa Cruz is wrong according to a 1927 California
Supreme Court Ruling."

> "Comments: Official boundaries of Monterey-Santa Cruz, as determined by the 
> California Supreme Court in Ocean Industries v. Superior Court of California, 
> in and for Santa Cruz County (1927) 200 Cal. 235. The decision held that 
> Monterey Bay as a "closed bay" under law, and there is treated as if it were 
> land for purposes of State and County jurisdiction -- which, in the case, 
> held that Santa Cruz County could enforce fishing regulations in SCZ waters 
> in Monterey Bay more than 3 miles offshore."

"I have a longish discussion at
http://creagrus.home.montereybay.com/MtyBay-boundaries.html";

> "Government Code section 23127 defines Monterey County as "beginning in the 
> Pacific Ocean, at the southwest corner of Santa Cruz [County]; thence east to 
> the mouth of the Pajaro River". Likewise, section 23144 defines Santa Cruz 
> County, in pertinent part, as "westerly along said [Pajaro] River" along the 
> northern line of San Benito and Monterey "to the Bay of Monterey, and three 
> miles westerly into the ocean."

> "The ... map shows a line across Monterey Bay in this tiny sliver of the Bay 
> that runs not > "west-east" but about WSW-ENE and connects up with the 
> "nearest point of land" line at the 3 mile limit west of Monterey Bay."

> "To see images go to 
> http://creagrus.home.montereybay.com/MtyBay-boundaries.html";

Does anyone want to look into this?
- Joseph

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Joseph Eisenberg]

In California some roads have signs that say “End Freeway”, about 1/2 mile
before the first intersection, eg I-8 in San Diego.
On Thu, Nov 29, 2018 at 1:04 PM Evin Fairchild  wrote:

> Nobody is saying that we should tag as motorways a road with a surface
> intersection. I don't understand what it is that we're saying that's
> causing you to come to that conclusion. We are simply saying that the
> first surface intersection that a road comes across is where the motorway
> should change to trunk.
>
> -Evin
>
> On Nov 28, 2018 7:42 PM, "Paul Johnson"  wrote:
>
> On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:
>
>> Unless there have been significant changes since I moved away, it should
>> be tagged motorway between the IDL and the light at Apache/Gilcrease
>> Extension. Before the Gilcrease was extended west of US-75, the Tisdale
>> should have been tagged entirely as motorway. Adding the intersection did
>> not change the character of the road south of the Gilcrease extension or
>> the rights of adjacent landowners, so I don't see any particular reason to
>> reclassify that segment.
>>
>
> Right, but where are we getting that motorways have surface intersections
> now?
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Strange city boundary: Lee, Illinois

[Joseph Eisenberg]

Yes.
New York City has several counties within its borders.
I believe Houston and several other cities in Texas cross county borders.
On Wed, Nov 14, 2018 at 11:08 PM Adam Franco  wrote:

> Last summer there was a big thread Differences with USA admin_level
> tagging
> 
> that talked a lot about odd cases in the US. As one example, Kevin Kenny 
> pointed
> out
>  
> Geneva,
> NY 
> which apparently has a portion in a second county. I haven't re-read the
> who thread, but I seem to remember others mentioning a number of other
> situations where administrative areas really can't be represented in a
> cleanly nested way.
>
> Best,
> Adam
>
> On Wed, Nov 14, 2018 at 8:49 AM  wrote:
>
>> Hi,
>>
>> are there cities (admin level 8) in the USA which  part of two counties?
>>
>> see: https://wambachers-osm.website/images/osm/snaps_2018/lee.png
>>
>> left: Lee County
>>
>> right: DeKalb County
>>
>> there are some more, but i would like to know if that is ok. In Germany
>> this is impossible.
>>
>> Regards
>>
>> walter/Germany
>>
>> --
>> My projects:
>>
>> Admin Boundaries of the World 
>> Missing Boundaries
>> 
>> Emergency Map 
>> Postal Code Map (Germany only) 
>> Fools (QA for zipcodes in Germany) 
>> Postcode Boundaries of Germany
>> 
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] California is too big ;)

[Joseph Eisenberg]

Counties in California are very different in size and population. A few in
the mountains have under 20,000 people and a rather small area. But Los
Angeles county has 10 million people and covers a huge area.

If 2 files become too big in a few years, it would be most useful to break
up the states into metropolitan statistical areas plus rural regions, but I
think this can wait. In the meantime NorCal / SoCal will work.
On Wed, Nov 7, 2018 at 6:29 AM Simon Poole  wrote:

> Jumping in here slightly unwarranted, but what the heck :-).
>
> I think the question is less where N vs S California is but more if
> there is a regional split of California that would make sense from a
> processing pov. Is for example somebody likely to do something with a
> North-CA extract, or if you would want to do something on a smaller
> scale, would that clearly be at a county level. Frederik is likely to
> groan at that idea, but some how I suspect that CA county level extracts
> would be comparable with states in other countries.
>
> Simon
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] California is too big ;)

[Joseph Eisenberg]

Northern and Southern California would work; make the split along the
county boundaries just north of Bakersfield, which conveniently follow one
line of latitude.

It would also be possible to split the State into Northern, Central and
Southern regions, but this would be harder to define.

Joseph

(PS: having separate files for each large island or region in Indonesia
would be very helpful; eg Sumatra, Java, Kalimantan/Borneo, Sulawesi, Bali,
NTT, the Moluccas, and Papua. The French server has individual provinces)
On Tue, Nov 6, 2018 at 5:40 PM Frederik Ramm  wrote:

> Hi,
>
> on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
>
> Every once in a while I check the list of not-yet-split countries and
> split up the largest of them. The current top of the list is
>
> 1. Netherlands
> 2. California
> 3. Indonesia
> 4. Spain
> 5. Czech Republic
> 6. Brazil
> 7. Ontario
> 8. Norway
> 9. Austria
> 10. India
>
> Hence the next country I'll split up is the Netherlands, but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
>
> So I wonder:
>
> 1. is there already a site where someone interested in only a subset of
> California can download current data and potentially also daily diffs?
>
> 2. is there a demand for this?
>
> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us