Re: [OSM-talk] ODbl concerns

[Adam Franco]

Robert, I applaud the Victoria government for using and collaborating on
OSM data! As others have shared I think direct government involvement with
and contributions to OSM are a great strategic direction.

Here in the USA our federal government is required by law to put all of its
publications in the public domain, which unfortunately disallows direct
contributions to OSM (though this public domain data is of course cleared
for inclusion in OSM by non-government contributors). In light of this
legal requirement, the OpenStreetMap-US foundation has partnered with US
Government agencies on the Public Domain Map project
. This project
utilizes modified versions of the OSM tool-chain (database, schemas,
editors, etc) to allow government staff and volunteers to create and
validate map data in the public domain, making it possible to incorporate
in US Government works and be readied for downstream inclusion in OSM.

I wouldn't want to suggest that Public Domain Map is the best option if
national laws allow direct contributions to ODBl datasets, but did want to
mention it as I feel that Public Domain Map is a clever work-around to our
local legal situation that brings our government as close as it can to
preparing data for OSM without violating its own licencing rules.

On Sun, Jul 2, 2023 at 8:13 PM Robert C Potter (DTP) via talk <
talk@openstreetmap.org> wrote:

> Hi OSM,
>
> Representing the state transport authority (Department of Transport and
> Planning) we have made the strategic decision to use OSM as our
> foundational mapping data source.  We are confident that this is a decision
> will be of value to both ourselves improving the management of the networks
> (road, Train, Bus, tram) and adding significantly to the citizens of the
> state.
>
> Our intended use of OSM is built on an extract being done then validating
> that extract for the gazetted/official place and road names. The resultant
> validated dataset will be shared that via our Opendata portal.  Our state
> government has a strong commitment to sharing all data openly.  We are
> currently developing that process and should be in production by the end of
> the year.
>
> Alas, there has been concern from our distribution partners with the ODbl
> license requirement to "Share alike".  You know these companies; Google,
> Here, Tomtom and Apple.
>
> The information we would share, and all shared as ODbl;
>
>- Disruptions
>- Heavy vehicles
>- Bicycles routes
>- Public transport routes and timetables
>
> I am wondering how we, can continue engage with these partners and use and
> improve OSM.
>
>
>
> If you have any further queries, please do not hesitate to contact me.
>
>
>
> Regards,
>
>
>
> Robert Potter
>
> *Helping people use the power of location to make better decisions*
>
> Manager, Spatial Data Strategy
> Department of Transport and Planning
>
> 1 Spring Street
>
> MELBOURNE 3000
>
>
> *M *0402 484 739
>
> *F* 03 9935 4111
> *E *robert.pot...@roads.vic.gov.au
> *W dtp.vic.gov.au *
>
>
> I acknowledge the Traditional Aboriginal Owners of Country throughout
> Victoria and pay my respect to Elders past and present and emerging and to
> the ongoing living culture of Aboriginal people.
>
> DISCLAIMER
>
> The following conditions apply to this communication and any attachments:
> VicRoads reserves all of its copyright; the information is intended for the
> addressees only and may be confidential and/or privileged - it must not be
> passed on by any other recipients; any expressed opinions are those of the
> sender and not necessarily VicRoads; VicRoads accepts no liability for any
> consequences arising from the recipient's use of this means of
> communication and/or the information contained in and/or attached to this
> communication. If this communication has been received in error, please
> contact the person who sent this communication and delete all copies.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

[Adam Franco]

Spot on, Greg!

If this was Discourse I'd just leave a heart emoji, but since I have to
type a reply anyway, I'd like to address some components of what makes
communication civil and collaborative:
1. Assume positive intent until proven otherwise.
2. Don't assume that the reader's background knowledge and context is the
same as yours.

I believe that these transcend any American/German cultural differences.
There are other components as well I'm sure, but if we violate either of
these in our writing, then our messages we come off as uncooperative at
best.

Both writers and readers need to keep these in mind, though I believe that
the writer has a more immediate responsibility to show the intent of their
words, especially if they want to be understood by a global audience.


On Thu, May 4, 2023, 8:46 AM Greg Troxel  wrote:

> "Brian M. Sperlongano"  writes:
>
> > I would caution against hyper-simplifying the combativeness of the
> mailing
> > lists as "cultural differences". I can think of several German
> participants
> > on Slack and Discord that dispel this stereotype.  Similarly, I can think
> > of several American commenters who are notoriously abrasive on the
> mailing
> > lists.
>
> +1 to Brian's comment.  Going further, I think a "we are having problems
> from cultural differences" is more than an over-simplification -- I
> think it is basically an incorrect conclusion.
>
> I lived in a dorm that had about 25% people from US/Canada (which I know
> aren't the same place but they aren't so far off culturally :-) and 75%
> from a very large number of other countries.  For a year I served as
> dorm president and thus had a clearer view of conflicts.  My experience
> was that people mostly got along, and when they didn't, it was almost
> always because some individuals were just fundamentally unkind and
> unreasonable.  It didn't matter what country they came from; I knew nice
> people and jerks from many countries (although nice or nice-enough
> people were the overwhelming majority).  Yes, there were some obvious
> differences in degree of directness, but those were not the problems.  I
> have seen this same pattern in the online world -- it is 90%+ about
> individuals and how they approach others, not about national culture.
>
> I have also participated in NetBSD, and there too most people try to
> work together to achieve project goals despite differences.  I can think
> of several problematic people over the years -- surely the same as any
> other project if you knew the details -- and for obvious reasons I won't
> give any details.  But I will say that I know which countries they are
> from, that I also know many people from those same countries that are
> courteous and constructive, and that I don't think the problems are
> about national culture -- they are firmly individual.
>
> So I would say that the biggest issue is that some people are just not
> trying to be collaborative and are the kind of basically unkind people
> that I would avoid entirely in offline life.  The second biggest issue
> is a practice of giving a very short blunt opinion with no willingness
> to try to communicate the subtleties -- and I mean this over the medium
> term, rather than condemning anyone for a single short email where they
> say what they think succinctly.
>
> As for strongly-held beliefs about licensing, I think that's perfectly
> ok.  (IMHO we believe in open data, and a lot flows from that ethically,
> but I realize not everybody sees it that way.)  I also don't see that as
> the core cause of uncivility.
>
> What we really need is for people to be at least civil if not
> courteous.  That can't really be done with rules; it can only be done in
> my experience by shunning a few individuals, and trying to lead by
> example.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[Adam Franco]

As discussed in this Practical Engineering episode
, the publicly visible nature
of the electrical grid makes security through obscurity very difficult if
not impossible. He notes that ballistic-resistant walls around transformers
are a likely future change to protect transformers from these sorts of
attacks from covert off-site locations.

On Thu, Jan 19, 2023 at 12:48 PM john whelan  wrote:

> I seem to recall there are fewer rifles per head of population in the UK.
> The problem is more a North American one although with the ease of which
> guns can be 3D printed it could be a UK eventually.
>
> On a side issue I wonder if Microsoft's building detector could pick out
> telephone boxes in the UK?
>
> Cheerio John
>
> On Thu, Jan 19, 2023, 12:40 Nick Whitelegg 
> wrote:
>
>>
>> Even still, the location of major substations (e.g the 400-132kv type)
>> isn't really a secret. I could reel off quite a few in the UK without even
>> looking at a map.
>>
>> Nick
>>
>>
>> --
>> *From:* john whelan 
>> *Sent:* 19 January 2023 17:38
>> *To:* Nick Whitelegg 
>> *Cc:* OpenStreetMap talk mailing list 
>> *Subject:* Re: [OSM-talk] Should we be mapping transformers and
>> powerlines?
>>
>> I accept powerlines are fine and visible on other maps but the case for
>> transformers isn't quite so strong.
>>
>> Cheerio John
>>
>> On Thu, Jan 19, 2023, 12:15 Nick Whitelegg via talk <
>> talk@openstreetmap.org> wrote:
>>
>>
>> I thought the whole point of OSM was to map the ground truth?
>>
>> Power lines are there, and they are an important navigational aid when
>> out walking or hiking.
>>
>> And besides, just about every commercial mapping provider that I've used
>> shows them. The OS does, as do maps that I've seen in a range of
>> continental European countries.
>>
>> Nick
>>
>>
>> --
>> *From:* john whelan 
>> *Sent:* 19 January 2023 03:03
>> *To:* OpenStreetMap talk mailing list 
>> *Subject:* [OSM-talk] Should we be mapping transformers and powerlines?
>>
>> Apparently you can do a lot of expensive damage by firing a rifle bullet
>> through them as happened more than once in the US and given the situation
>> in Europe at the moment is there a risk that something similar could happen
>> there?
>>
>> Should we have a process that says some things should not be mapped?
>>
>> I seem to recall that the location of the pipeline that supplies aviation
>> fuel to airports is considered an official secret in the UK.
>>
>> Thoughts?
>>
>> Thanks John
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>> 
>>
>> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] maps missing attribution on usnews.com

[Adam Franco]

I was just reading through the recent US News & World Report college
rankings and saw my OSM handiwork in their maps locating each school, but
without any attribution. Tiles look to be served from their own domain.

Example: https://www.usnews.com/best-colleges/middlebury-college-3691

   - Map in page screen-shot
   

   - Map detail screen-shot
   


Is this considered "Substantial Usage" and shall I follow the rest of the
steps noted in the wiki?
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution

Thanks for any feedback,
Adam
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

[Adam Franco]

There were several threads in talk-us during July that discussed the
problems of access=private on driveways:
https://lists.openstreetmap.org/pipermail/talk-us/2020-July/thread.html

   - [Talk-us] access=private on driveways (was: Deleting
   tiger:reviewed=no/addr:street for routes)
   
   - [Talk-us] access=private on driveways
   

Long story short, if access=private is "added by default", then there is no
way to differentiate between "normal driveways" where uninvited guests
might raise eyebrows due to social convention and actually-signed/gated
driveways that explicitly prohibit access.

If access=private is "added by default" and routers are forced to ignore it
to reach the final destination, then there is no way for them to work out
which routes might actually be allowed conditionally to access the
destination when circumstances are appropriate (deliveries, political
canvassing, invited guests, etc) and which ones truly are prohibited via
signage, barriers, etc.

On Sun, Aug 16, 2020 at 11:48 PM Tod Fitch  wrote:

> Don’t recall if it was on talk-us or tagging, but yes there was a recent
> discussion on this.
>
> If I recall correctly it seemed access=destination was preferred if you
> were going to tag an access value.
>
> But since a significant number of driveways (nearly all?) are not
> physically through roads there is little danger of a router directing you
> on it unless your destination is on the driveway, so tagging an access=*
> really isn’t needed most of the time.
>
> —Tod
>
> On Aug 16, 2020, at 8:33 PM, Skyler Hawthorne  wrote:
>
> Was there a previous discussion about this that I can catch up on?
> Driveways seem like access=private is appropriate across the board, not
> just when there is explicit signage. If you drive onto someone's house's
> driveway without permission, you are trespassing on their property.
>
>
> ___
> 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] Interested in importing address points in New York State

[Adam Franco]

Skyler, I was able to reach out to Vermont's State GIS office and received
an explicit usage grant that is now recorded in the OSM wiki
<https://wiki.openstreetmap.org/wiki/Vermont#Resources>. While former
similar efforts in NY may have failed in years past, a new request might
succeed in getting a more blanket approval that could cover this and other
OSM projects. In case it help you or others as a starting point, here is
the message I used for Vermont:

-- Forwarded message -
> From: Adam Franco 
> Date: Wed, Sep 20, 2017 at 4:59 PM
> Subject: Vermont/VCGI data usage in OpenStreetMap
> To: 
>
> Dear Leslie,
>
> I contacted you about this topic several years ago (2013!) but then
> shifted my focus to other projects and never followed up again.
>
> I am a contributor <https://www.openstreetmap.org/user/Adam%20Franco> to
> the OpenStreetMap <https://www.openstreetmap.org/> project [1], a
> collaborative open project to create a global geodata set freely usable by
> anyone [2].
>
> We respect the IP rights of others and I write to ask if we can use data
> published by VGCI, in particular [but not necessarily limited to] the
> following data-sets:
>
>- VTrans::vt-road-centerline
><http://geodata.vermont.gov/datasets/VTrans::vt-road-centerline>
>- vt-boundaries-all-lines
><http://geodata.vermont.gov/datasets/vt-boundaries-all-lines>
>- VT Hydrography Dataset
><http://geodata.vermont.gov/datasets/acda0d7626644d9ca4d2c00dbe0141e0_10>
>- VT E911 Site Locations
>
> <http://geodata.vermont.gov/datasets/vt-e911-site-locations-building-address-points>
>
> I've read through the VCGI Warranty/Copyright document
> <http://vcgi.vermont.gov/sites/vcgi/files/warehouse/VCGI_Warranty_Copyright_Notice_2013.pdf>
> and while it seems to my lay reading that importing data from these
> data-sets into the OpenStreetMap would constitute a "value-add" and
> therefore allow such use, it would be helpful to the community to have a
> clear statement allowing our use of the data.
>
> At the most simple, I would seek a statement like this:
>
> "The State of Vermont and its Vermont Center for Geographic Information
> has no objections to geodata derived in part from the
> VTrans::vt-road-centerline, vt-boundaries-all-lines, VT Hydrography
> Dataset, and VT E911 Site Locations data sets being incorporated into the
> OpenStreetMap project geodata database and released under a free and open
> license" [1]
>
> A broader, less itemized grant might be even better, but I'm not sure if
> your agency might have concerns about over-broad usage grants. Maybe
> something like this:
>
> "The State of Vermont and its Vermont Center for Geographic Information
> has no objections to geodata derived in part from data-sets published by
> the VCGI being incorporated into the OpenStreetMap project geodata database
> and released under a free and open license"
>
> I also ask that whatever statement you are prepared to make can be made
> public for information purposes, posting it to the project's data-source
> documentation <https://wiki.openstreetmap.org/wiki/Potential_Datasources>
> for others to reference.
>
> Below is a fact sheet. If you would like any more information, I will do
> my best to help or can ask our project's License Working Group to get in
> touch with you.
>
> Regards, Adam Franco
>
>
> *Fact Sheet *
>
> [1] The OpenStreetMap project currently has over 750,000 registered
> contributors worldwide. Our main website is http://www.openstreetmap.org
>
> [2] We are mandated to make our geodata available in perpetuity under a
> free and open licence. We are not allowed to use a commercial license, but
> commercial organisations are allowed to use our data under similar terms.
>
> [3] Our data is currently published under the Open Database License 1.0,
> http://www.opendatacommons.org/licenses/odbl/
>
> [4] Most of our geodata is contributed by individuals. However, we are
> very grateful when able to incorporate or derive from other geo-data
> datasets where license terms are compatible.
>
> [5] We formally attribute all such sources at
> http://wiki.openstreetmap.org/wiki/Attribution, using any specific
> wording if you request. We also try to provide a link to this page with any
> extract of data from our database. However, for reasons of practicality, we
> do not require end-users to repeat such attribution since it runs into
> hundreds.
>
> [6] We also keep a public track of third party data use at
> http://wiki.openstreetmap.org/wiki/Import/Catalogue and usually have a
> project page for each dataset, describing how we use it and whether 

Re: [Talk-us] access=private on driveways

[Adam Franco]

On Tue, Jul 14, 2020 at 7:46 AM Greg Troxel  wrote:

> ...
>
> As for access=private 'breaking' routing, this discussion feels very
> much like tagging for the router, instead of tagging what is and fixing
> the router.  If you are driving someplace and you have permission, then
> it should be expected that you can use access=private ways to get to
> your destination.  Humans konw this, and while most people wouldn't
> randomly drive down other people's driveways, it's obvious that if you
> are invited to a house it's ok to use their driveway.
>
> So a router that does not allow use of access=private for a final
> segment, by default, is broken.
>

There is a big problem with this interpretation of tagging ways with
access=private that are not posted/gated to prevent access but are not used
by convention/norm: Doing this makes it impossible to distinguish these
from roads that *are* gated/posted.

As an example, a local airport has gated service roads and driveways
 to
get to a variety of maintenance and airline buildings. These are
appropriately access=private because they are gated and only employees can
use them. Routers need to be able to direct customers/public via the
close-by access=public/destination/customers roads and not try to use the
access=private roads. If access=private is used for most residential
driveways and routers need to treat access=private as a thing to be ignored
for final routing, they will get this airport situation wrong.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Deleting tiger:reviewed=no/addr:street for routes (was: Streaming JOSM -- suggestions?)

[Adam Franco]

>
> On Sun, Jul 12, 2020 at 6:12 PM Alex Hennings 
> wrote:
>
...
> I've developed a strong opinion that a privately owned road (or anything
> else) should be tagged "ownership=private". Don't confuse the ownership
> with the access rights even though we use the same word for them in
> English. Them being "often posted..." doesn't mean we can assume they
> always are. Please only record data that there is evidence for.
>

I just want to second this statement. I'm quite frustrated that the TIGER
import added access=private to privately maintained roads that should
instead be tagged with ownership=private. This broad-scale mis-tagging
suggests to later mappers that this is the way to tag privately maintained
roads, leading to overly restrictive access restrictions that don't match
reality.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Adam Franco]

>
> > I would imagine that the parent NF object that has the name
> > "Green Mountain National Forest" would contain members that had
> > protect_class=6 (resource extraction), protect_class=1b (wilderness),
> > protect_class=5 (recreation areas, Appalation Trail corridor), etc.
>
> Again, yes.  To clarify, the NF object itself (the multipolygon's tags,
> I'd discourage calling this "parent" as it means something else in the
> context of relations and super-relations and we shouldn't confuse those)
> would have the name=Green Mountain National Forest + protect_class=6 tags
> (plus others, like operator=USFS).  AND the additional members "associated
> with the NF" (like wilderness areas which are "within the NF") would be
> separate polygons with* role inner as members of this NF relation, but
> ALSO with their OWN tags (like protect_class=1b and name=Breadloaf
> Wilderness).  Yes, this makes "holes" of wilderness inside of the NF, but
> think about it:  if the "whole thing less inholdings and stuff that's
> different" (outer minus inners) really deserves protect_class=6 AND the
> "inners that are wilderness"* are tagged with protect_class=1b, well,
> we've got it!  Sure, doing it like that makes it logically appear (and
> maybe actually be) that wildernesses are excluded from the NF, but in the
> sense by which we tag them, they ARE excluded, even as they are surrounded
> by something with a "lesser" protect_class.  Plus, it is the same agency
> tagged both on the multipolygon (for the outer) and its member inners.
> They are logically excluded by being inners, but because the MP is tagged
> operator=USFS (and so should be the inner wildernesses), we "add them back
> in," at least for their operator, by virtue of that tag being on the inners
> (But being differently tagged with protect_class=1b, as they should be).
> Whew!
>
(emphasis added)

Steve, I think that cutting wilderness/etc areas out of the NF polygon is
logically problematic as these *are* part of the NF, just with extra
restrictions. You don't leave the NF when you enter the wilderness area.
This is kind of like cutting out a section of a highway from its parent
route relation just because a portion of it doesn't allow heavy loads and
has additional restrictions. One significant issue with this is that
"adding them back in by operator" would have to be handled by data
consumers to understand the model, a new and extra burden.

I'd rather see a tagging structure that was logically consistent, where a
query of "is this point in the NF?" always returns the correct answer for
any point. This might be more complex than just a multipolygon and use
parent/child relations (that was intentional language choice on my part).
Here's an example:

   - Parent relation:
   - name=Xxxx National Forest
  - operator=United States Department of Agriculture, Forest Service
  - ownership=national
  -

*(NOT protect_class=6 as that will not be true for all members) *
   - One (or more) child multipolygons for all of the "normal" areas:
  - boundary=protected_area
  - protect_class=6
  - protection_title=National Forest
   - Child multipolygons for each wilderness area (if any):
  - boundary=protected_area
  - protect_class=1b
  - protection_title=Wilderness
  - name=*
   - Child multipolygons for each recreation area (if any):
  - boundary=protected_area
  - protect_class=5
  - protection_title=Recreation/Landscape
  - name=*
   - Additional child multipolygons for otherwise designated parts of the
   NF not included above.

Such a structure could have only a single object for those NFs that have a
single uniform protection class, but expands gracefully to more complex
situations where those exist. The big challenge with this scheme is that I
think that the parent relation may need to be a boundary relation
<https://wiki.openstreetmap.org/wiki/Relation:boundary> instead of a
multipolygon relation because ways may be shared between children, eg the
border between a protect_class=6 and a protect_class=1b area would be a
role=outer of both, potentially resulting in an invalid multipolygon
<https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Overlapping.2C_unclosed_member_ways_belonging_to_the_same_role>.
That said, I'm not quite sure of the nuances of valid/invalid multipolygons
that are children of a parent relation and I'd be happy to be wrong on this
point.

On Fri, Jun 26, 2020 at 1:58 PM stevea  wrote:

> Adam Franco  writes (about my 1, 2, 3 post
> potentially defining NF MPs, now clarified that 1 isn't "all enclosing")
> > I think this is correct:.
>
>
> He continues:
> > If there is consensus on dropping (3), then a system for mapping

Re: [Talk-us] National Forest boundaries

[Adam Franco]

>
> On Thu, Jun 25, 2020 at 1:40 AM stevea  wrote:
>
A refinement, perhaps Bradley and others agree with me, perhaps not.
>
> A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to that
> later) of three kinds of things:
>
> 1) An "outer" (but not the biggest one) which is "the enclosing land which
> USFS manages, except for inholdings, below,"
> 2) Zero to many "inner" polygons, representing inholdings (and with the
> usual "hole" semantic of exclusion from 1), above and
> 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is
> the geographic extent to which USFS may or might "have influence to someday
> manage."
>
> If we ignore 3) as "not real, but rather aspirational or in the future
> rather than the present, and certainly not on-the-ground" then an OSM
> multipolygon consists of simply 1) plus 2).
>

I think this is correct.

The difference between the "aspirational/congressionally mandated" area (3)
and the owned/managed area (1-2) my local NF (Green Mountain National Forest
)
is dramatic. Both are complex shapes, but the (1-2) area is immensely
fragmented and rarely aligned with the (3) area. The (3) boundary is mostly
useful for low-zoom maps to show an approximation of the NF region -- it is
pretty meaningless for high-zoom usage (in my opinion).

If there is consensus on dropping (3), then a system for mapping NFs as
(1-2) should be possible to figure out. That said, how that OSM object is
assembled and tagged may be tricky. In the Green Mountain National forest
the (1-2) area contains a large mix of areas with different protections

(detail map). I would imagine that the parent NF object that has the name
"Green Mountain National Forest" would contain members that had
protect_class=6 (resource extraction), protect_class=1b (wilderness),
protect_class=5 (recreation areas, Appalation Trail corridor), etc. Some of
these child boundaries would have their own names and additional tags,
others not.

I'm not sure what tagging would be appropriate for the NF object itself
maybe these as a starting point?

   - name=*
   - boundary=national_park
   - operator=US Forest Service
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Adam Franco]

Three years ago I updated the tagging and relations
 of the Green Mountain
National Forest  in Vermont
after some discussion in the Tagging list (start
,
after

some comments from Kevin).  What I ended up doing is setting the outer
"proclamation boundary" as one relation
 tagged with
boundary=national_park +
boundary_type=protected_area + protect_class=6 and the actual parcels are a
separate relation  tagged
with boundary=protected_area + protect_class=6 (and leisure=nature_reserve
for rendering -- not sure if that is still needed). Wilderness and
recreation areas within the National Forest are not members of the main
parcel relation, but instead are their own ways/relations with tagging that
indicates the higher level of protection in them such as protect_class=1b
for wilderness areas (examples: Joseph Battell Wilderness
,  Big Branch Wilderness
) and protect_class=5 for
recreation areas (example: Moosalamoo National Recreation Area
).

I can't say that this tagging is necessarily correct, but it has proven to
be pretty useful in a few ways:

   1. The "proclamation boundary" is a big area that provides an
   appropriate name on low-zoom maps.
   2. Having the parcel relation (with cut-outs for in-holdings) is super
   useful when exploring the forest and wanting to be aware of the potential
   for no-trespassing signage.

I haven't looked at other National Forests in depth, but some in CO
(like Roosevelt
National Forest  and Pike
National Forest ) are just
one big relation with boundary=national_park + boundary_type=protected_area
+ protect_class=6  and no separate parcel relations. If the actual outer
"proclamation boundary" matches the main extent of the parcels that is
probably much simpler. In the case of the Green Mountain National Forest
the "proclamation boundary" almost never matches the outer edge of the
parcels, but covers a much wider area -- hence mapping both.

Hope this helps!
Adam

On Sat, Jun 20, 2020 at 11:08 PM brad  wrote:

>
> On 6/20/20 6:19 PM, Mike Thompson wrote:
>
>
>
> On Sat, Jun 20, 2020 at 5:45 PM stevea  wrote:
> >
> > I think we need both as well.  I've been doing this while watching the
> evolution of how we best do this as I participate in a "do our best, always
> better" efforts to accomplish this.  Even now!
> >
> > The idea of the first kind is simply a relation with a focus on the / a
> polygon with the outer (-most) membership.  The idea of the second kind is
> one of these plus a carefully crafted inner membership, often made up of a
> complex inholding distribution containing many sometimes complex themselves
> inner polygons.
> Thanks Steve for your insightful comments.
>
> I was thinking just create separate polygons for inholdings, tagged with
> access=private and possibly ownership=private
>
> Mike
>
> I think its simpler and better to just create an inner boundary as was
> done with the Coconino NF
> ___
> 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] Trunk versus motorway

[Adam Franco]

I'm not saying that the surface junction itself would still be motorway (or
even the area of reduced speed approaching it), but once one is far enough
beyond those limiting features and the speeds and other aspects are the
same as the rest of the motorway, the roadway is functionally a motorway. I
think the issue is that you take the word "include" to mean any segment
possibly touching a surface junction, at any distance from that junction.
It seems that most of the rest of us feel that there is some distance (e.g.
over the horizon, miles away, before a speed reduction, etc) where junction
is far enough off that it is separate from the character of the roadway one
is on.

I've never been to OK and don't know your roadway in question well enough
to weigh in on that specific case, but I would oppose a rule that said that
motorways can never continue to the position where the road character
changes (e.g. signage, speed reduction) leading to a final surface
intersection.

On Sun, Dec 2, 2018 at 5:03 PM Paul Johnson  wrote:

> The commonly accepted definition of freeways in the US excludes surface
> junctions, whereas expressways (trunks) does include intersections.  I
> honestly am surprised a group of roadgeeks isn't more attuned to this
> distinction.
>
> On Sun, Dec 2, 2018 at 3:15 PM Adam Franco  wrote:
>
>> On Sun, Dec 2, 2018 at 1:36 AM Paul Johnson  wrote:
>>
>>>
>>> On Sun, Dec 2, 2018 at 12:30 AM Bryan Housel  wrote:
>>>
>>>> I do understand your point, but a dozen or so people on talk-us and the
>>>> six or so people on that changeset 64919426
>>>>
>>>
>>> Well, 1 person, an AA roads troll and like 5 sockpuppets.  There's also
>>> a number of people in this thread that do agree with me.
>>>
>>>
>>>> discussion all disagree with you.  Is there nothing that would make you
>>>> reconsider?
>>>>
>>>
>>> Get the commonly used definition of a freeway changed to include
>>> intersections.  Good luck!
>>>
>>
>> Since you are asking for more declaration of support/opposition, I'm a
>> relatively disinterested-in-motorways mapper that has been following along
>> with this thread. Paul, I think your read of a motorway definition is
>> overly rigid and I agree with Richie, Bryan, and the others that a motorway
>> classification may continue beyond the last interchange.
>>
>> If one is traveling past the last interchange one may be traveling in a
>> "motorway zone" where high speeds, grade separation of crossing roads, dual
>> carriageway, etc all continue to exist. As Richie pointed out, there will
>> be some place where "caution freeway ends", "intersection ahead" or slowing
>> speed limit signage indicates a transition out of the motorway zone to
>> something else. That seems like a vastly more appropriate place to change
>> the tagging from motorway to trunk/primary. Choosing the point of the last
>> interchange doesn't make sense as there may be many miles on both sides of
>> the last interchange where the roadway is functionally the same -- where
>> standing and looking at the road it shows all of the characteristics of a
>> motorway. It is confusing to think that an at-grade intersection far over
>> the horizon would force a long final segment of road to change
>> classification.
>> ___
>> 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] Trunk versus motorway

[Adam Franco]

On Sun, Dec 2, 2018 at 1:36 AM Paul Johnson  wrote:

>
> On Sun, Dec 2, 2018 at 12:30 AM Bryan Housel  wrote:
>
>> I do understand your point, but a dozen or so people on talk-us and the
>> six or so people on that changeset 64919426
>>
>
> Well, 1 person, an AA roads troll and like 5 sockpuppets.  There's also a
> number of people in this thread that do agree with me.
>
>
>> discussion all disagree with you.  Is there nothing that would make you
>> reconsider?
>>
>
> Get the commonly used definition of a freeway changed to include
> intersections.  Good luck!
>

Since you are asking for more declaration of support/opposition, I'm a
relatively disinterested-in-motorways mapper that has been following along
with this thread. Paul, I think your read of a motorway definition is
overly rigid and I agree with Richie, Bryan, and the others that a motorway
classification may continue beyond the last interchange.

If one is traveling past the last interchange one may be traveling in a
"motorway zone" where high speeds, grade separation of crossing roads, dual
carriageway, etc all continue to exist. As Richie pointed out, there will
be some place where "caution freeway ends", "intersection ahead" or slowing
speed limit signage indicates a transition out of the motorway zone to
something else. That seems like a vastly more appropriate place to change
the tagging from motorway to trunk/primary. Choosing the point of the last
interchange doesn't make sense as there may be many miles on both sides of
the last interchange where the roadway is functionally the same -- where
standing and looking at the road it shows all of the characteristics of a
motorway. It is confusing to think that an at-grade intersection far over
the horizon would force a long final segment of road to change
classification.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Adam Franco]

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

Re: [Talk-us] State Open Data

[Adam Franco]

I've added Vermont's center-line
 info to
the spreadsheet. As someone who does a lot of filtering of OSM roads based
on surface, exposing surface info to a broader group of editors would be a
fabulous win. Thanks for heading in this direction!

To do my own surface entry I've resorted to side-by side JOSM and QGIS
windows with the latter showing a color-coded road-centerline file. As can
be imagined, most people won't go to this effort and hence US road-surface
data in OSM is pretty patchy to say the least.




On Tue, Aug 7, 2018 at 11:32 PM, Elliott Plack 
wrote:

> Maryland’s Transportation Basemap is already availability in iD and JOSM
> as an imagery source. We also have a slew of open datasets including
> centerline and speed limits. I’ll take a look at the doc and add some.
> http://data.imap.maryland.gov/datasets?q=transportation
>
> Kudos on getting this together!
> On Tue, Aug 7, 2018 at 23:27 Paul Johnson  wrote:
>
>>
>>
>> On Tue, Aug 7, 2018 at 9:00 PM, Clifford Snow 
>> wrote:
>>
>>> Ian,
>>>
>>>
>>> On Tue, Aug 7, 2018 at 9:30 AM Ian Dees  wrote:
>>>
 Thanks for putting this together, Clifford!

 I was collecting street centerline data as part of OpenAddresses a
 while ago here: https://github.com/openaddresses/centerlines

 I'm happy to add you to this repo if you want to use this repo or feel
 free to pull from this repo into your spreadsheet.

 My goal with this was to pull all this data into a single, country-wide
 layer to map in OSM with. I'm happy to help you down that path, if that's
 what you're thinking.


>>> That is exactly my goal - get all of the states with open data into a
>>> background image that people could use to trace from, much like your TIGER
>>> 2017 and previous years. My initial attempt will be just centerlines with
>>> street names. Later we need to add surface and other details.
>>>
>>
>>
>> This could present a feedback loop in Oklahoma, since OklaDOT's portal
>> can use (and in some datasets, does use by default) OSM.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> Elliott Plack
> http://elliottplack.me
>
> ___
> 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] Vermont Town Boundaries import

[Adam Franco]

I'm putting together documentation for an import of Vermont Towns at:
https://wiki.openstreetmap.org/wiki/Vermont_Town_Boundary_Import_2018

I'm currently looking at this import as a mostly manual process in JOSM
(relations, tags, etc) with the boundary geometry being the only thing not
hand-crafted. Any feedback or tips would be most welcome.

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

Re: [Talk-us] guidelines regarding roads access

[Adam Franco]

Thanks for the clear guidelines, Greg.

One additional note is that at least in my area, the TIGER import
incorrectly added access=private to many driveways and privately maintained
residential roads. Upon surveying these I've found that they are signed
"Private" or "PVT" on the street-name sign to indicate
private-maintenance/ownership (don't complain to the town about a lack of
snow-plowing/grading), but do not in reality have an access restriction.
Fixing these is a long process.

On Wed, Sep 13, 2017 at 9:13 AM, Andrew Matheny 
wrote:

> I agree with everything Greg has said.
>
> In the US, whether you tag a highway residential or service should
> generally be determined by its function, not its access.
>
> In the case of a gated community of single family homes, the named streets
> serve the same function as named streets in other non-gated single family
> neighborhoods. Hence I would tag those highway=residential and then
> access=private. Then service for any driveways or alleys.
>
> In the cases of other residential uses it would depend on the context.
>
> For townhome or other single-family attached dwellings with named roads
> that resemble detached single-family neighborhoods, I'd still tag as
> residential.
>
> On Trailer parks, I could be convinced to go with either residential or
> service depending on the trailer park. Some are built like high density
> single family neighborhoods and have named streets, in which case I would
> use a residential tag. When I've seen some (usually smaller) trailer parks
> where the highways resemble driveways more than they do streets, I've given
> those service tags.
>
> I could also go either way on multi-family developments (like garden-style
> apartment complexes), but usually I go with highway=service because they
> function more like the interior roads of a shopping center or business park
> even though they are technically residential uses. Access tags are added
> when appropriate.
>
> -Andrew
>
> ___
> 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] Differences with USA admin_level tagging

[Adam Franco]

On the "Gores" point: In Vermont, while these do not have any
administrative infrastructure and are managed by the State, they *are*
surveyed and named places with defined borders (shared with their
surrounding Towns). As such it likely makes sense to preserve them as
multipolygons each with their own name and detail tags. Since these areas
are exclusive of Town/City areas, it might make sense to give them the same
admin_level even though the mechanisms of administration are different.
They aren't States themselves, so a border=administrative,admin_level=4
smells wrong. I can't speak to the situation in Maine.


On Mon, Jul 10, 2017 at 7:39 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> Adam Franco writes his general agreement that Greg's assessment of
> Massachusetts applies to Vermont.  As I compare these two rows in the
> table, they are identical at admin_levels 6, 7 and 8, differing only in
> Precinct and Ward at 9 for the former and Village and District for the
> latter.  I do mention "Gores" (et al) in the Notes (specifically Note 18)
> as being best described as not part of any administrative division below
> the state (4) level.  I believe the process you describe for tagging
> villages and towns in Vermont is correct (to the extent they are actually
> census or special-purpose districts, as for water/sewer), however be aware
> that when such entities are "incorporated" they most likely rise to the
> level of deserving of an admin_level tag.  Adam, if any of that is not OK,
> please chime in.
>
> 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] Differences with USA admin_level tagging

[Adam Franco]

Just to weigh in from Vermont, the situation Greg mentions in Massachusets
also applies in Vermont:

On Jul 9, 2017 3:14 PM, "Greg Troxel"  wrote:
>
> From a state government point of view, the state is divided into
> municipalities., where every bit of land in the state is in exactly one
> municipal entity.  Whether a particular entity is Town vs City is merely
> a detail of the form of government, in terms of Board of Selectman and
> Town Meeting vs Mayor and City Council (more or less; there are multiple
> kinds of cities and that's messy, but they all I think have councils).
> Both have zoning bylaws, general bylaws, property tax, police chief,
> school committees, planning boards, conservation commissions, and
> various other things all the same.  The town meeting vs city council is
> really a minor distinction.  Sometimes a town changes into a city; I
> think Framingham just did or is about to.  Other than people who live
> there and elections, it's almost unremarkable except for rarity.
>
> In particular, cities are not contained within towns.  They are peers,
> fully equal in all ways, with a minor difference in government
> organization.  Nobody I know thinks one is at a higher level than the
> other.


In Vermont "Towns" and "Cities" are peers that are mutually exclusive, have
equivalent statutory rights and responsibilities, but differ only in the
mechanism of government (mayor + City Council for Cities, versus
Selectboard for Towns). Cities never contain towns or vice versa. They
should have the same administrative level in OSM.

Cites and Towns fully subdivide the counties, with one exception: "Gores
", small left-over
slices left unincorporated. These could be considered the same level of
hierarchy as Towns and Cities, but do not actually have a Town government
as they are too small, usually 0-20 residents. Their management handled by
the state in lieu of a functioning Town Government.

Vermont has many dense collections of homes and businesses that are
colloquially referred to as villages or towns. Some of these dense areas
may have municipal water/sewer and additional facilities such as a
post-office, however these densely populated areas do not have government
independent of the Town government. Their borders are amorphous and based
more on where services are provided and settlement patterns than any legal
status. These village centers were imported from TIGER as
boundary=administrative_area,admin_level=8, and I've started re-tagging
them as boundary=census when I come across them.



On Sun, Jul 9, 2017 at 3:25 PM, Kevin Kenny 
wrote:

> On Jul 9, 2017 3:14 PM, "Greg Troxel"  wrote:
>
>
> Kevin Kenny  writes:
>
> > So to me, what makes sense for New York:
> >
> > admin level 2 - United States of America
> > admin level 4 - New York State
> > admin level 5 - New York City, special case
> > admin level 6 - County, Borough (within New York City)
> > admin level 7 - Town, City
> > admin level 8 - Vlllage, hamlet (where borders defined), community
> > district (New York City), City of Sherrill
>
> It seems from reading your comments cities are within towns, that a
> house within a city is also within a town.
>
>
> Villages can span the borders between Towns, but in  all cases the
> residents of a Village are also residents of some Town.
>
> Cities are independent of Towns. Every resident of New York is a resident
> of exactly one City, Town, or Native American reservation.
>
> Single exception: For most purposes the City of Sherrill is administered
> as if it were a Village within the Town of Vernon.
>
> I'm pretty sure I have the ordering right. The specific level numbers are
> negotiable.
>
> A handful of Towns have Wards. I've never tried to map one and I'm not
> familiar enough with how they exist 'on the ground.
>
> So I do not follow putting
> them at the same level.  But it also seems that legally the notion that
> a house in a city is within the town has no consequence, in terms of not
> having to follow town law (perhaps there are no town laws) and not
> having to pay town taxes.  So I think you are saying that effectively
> being in a city means you aren't within a town, even though you are
> within the polygon.  Is that a fair read?
>
> The other question I have about your list is about town/city being at 7
> vs 8.  It seems that in most states, the city type of thing is at 8.
> The numbers are arbitrary, just leaving room for some 7 thing that might
> or might not exist.  But it seems good in terms of data consumers for
> ~everything that's sort of like a city (to include Mass towns) to be at
> 8, to reduce the need for special-case code.  That would put
> village/hamlet at 9, which strikes me as also aligned.
>
> This raises the notion if there are places in the US where there is
> something smaller than a county and bigger than a city in 

Re: [Talk-us] Green Mountain National Forest cleanup

[Adam Franco]

Thanks for those details, Kevin. The comparison is very helpful. The GMNF
seems to have only 3 classifications that I've been able to find:

   - Wilderness -- which should probably be protected_class=1b
   - National Recreation Area -- protected_class=5 (Wikipedia page
   <https://en.wikipedia.org/wiki/Moosalamoo_National_Recreation_Area>
   notes the ICUN class)
   - everything else -- probably protected_class=6

Thanks again for the feedback!

On Wed, Jan 18, 2017 at 12:15 AM, Kevin Kenny <kevin.b.kenny+...@gmail.com>
wrote:

> On Tue, Jan 17, 2017 at 8:59 PM, Adam Franco <adamfra...@gmail.com> wrote:
>
>> Thanks for another fabulously detailed reply Kevin!
>>
>> So it sounds like I'm on the right track then and it makes sense to leave
>> the broad outer boundaries as *boundary=national_park* and use the 
>> *boundary=protected_area
>> + leisure=nature_reserve* combo for the smaller US Forest Service-owned
>> parcels.
>>
>
> That's what I did when I reimported the Adirondack and Catskill data.
> There wasn't a clear consensus that the tagging was 'right' - but nobody
> really complained after the job was done.
>
> The tagging that I used is described in http://wiki.openstreetmap.org/
> wiki/NYS_DEC_Lands
> In the Catskills, there was a second category of public land:
> http://wiki.openstreetmap.org/wiki/Import:_NYCDEP_Watershed_
> Recreation_Areas
>
> I believe that it will be important, if anyone does get around to using
> the protected_area tagging, that protect_class and protection_object be
> something reasonable; that's something that's likely to affect the
> rendering. I'm not all that familiar with GMNF, so I don't know if there
> are a range of protection classes in it the way there are in the New York
> forests.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Green Mountain National Forest cleanup

[Adam Franco]

rve' tag is only slightly abused. A wilderness
> area, a wildlife management region, or a protected watershed (all of which
> permit recreational use) are all reserved to nature, and no US English
> speaker would be astonished at the tagging. I refuse to fight with the
> purists on this issue. There is no other suitable tag available that will
> ever be rendered on the main map.
>
> - the 'boundary=national_park' tag is abused on very few polygons, and can
> be reverted if and when there is ever a rendering of the protected_area
> status. I am not optimistic that this will occur.
>
> This issue has been discussed here many times before. The result is an
> impasse. This is one of the issues where nobody has been able to span the
> "US-European divide." I do not expect it ever to be resolved, so any
> tagging plan will either be an awkward compromise or result in invisble
> features.
>
> This is not a case of, "it's open source, so if you need it done, do it
> yourself." I'd be perfectly willing to do it myself, if it were not for the
> fact that "doing it myself" would involve building an entire server
> infrastructure to support a different rendering of the main map. That's not
> something within my capability.
>
> On Tue, Jan 17, 2017 at 12:57 PM, Adam Franco <adamfra...@gmail.com>
> wrote:
>
>> Hello all,
>>
>> I'm planning to do some cleanup of the Green Mountain National Forest in
>> Vermont and figured it might be useful to provide the opportunity for
>> feedback before embarking on this project.
>>
>> The Green Mountain National forest is currently mapped as two large
>> outer-area relations that include large swaths of private land and many
>> ways and relations that mark independent parcel boundaries -- the latter
>> having a multitude of tag schemes.
>>
>> Outer area boundaries:
>>
>>- northern section: https://www.openstreetmap.org/relation/2030450
>>- southern section: https://www.openstreetmap.org/relation/1610349
>>
>> Many parcel boundaries (examples):
>>
>>- https://www.openstreetmap.org/relation/6850907#map=13/44.044
>>4/-73.0668
>>- https://www.openstreetmap.org/relation/6631735#map=12/44.007
>>0/-72.9569
>>- https://www.openstreetmap.org/way/116060714#map=12/44.0123/-72.9418
>>- 
>>
>> There is very little consistency in the tagging of the parcel boundaries
>> -- many are tagged as boundary=national_park, others are tagged as
>> boundary=protected_area. As well, many [most?] are tagged with
>> landuse=forest even if they are sensitive areas (protected watersheds),
>> wilderness areas (no logging allowed ever), designated recreation areas, or
>> otherwise not open to logging.
>>
>> I propose to group all of the parcel boundaries into two super-relations,
>> one for the northern half of the GMNF and one for the souther half of the
>> GMNF. These super-relations would have:
>>
>>- type <https://wiki.openstreetmap.org/wiki/Key:type>=boundary
>><https://wiki.openstreetmap.org/wiki/Tag:type%3Dboundary>
>>- boundary <https://wiki.openstreetmap.org/wiki/Key:boundary>=
>>protected_area
>><https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area>
>>- protect_class
>><https://wiki.openstreetmap.org/wiki/Key:protect_class>=6
>>- protection_title
>><https://wiki.openstreetmap.org/wiki/Key:protection_title>=National
>>Forest
>>- protected <https://wiki.openstreetmap.org/wiki/Key:protected>
>>=perpetuity
>>- operator <https://wiki.openstreetmap.org/wiki/Key:operator>=United
>>States Forest Service
>>
>>- leisure=nature_reserve (this seemed to be recommended in the 
>> "Okanogan-Wenatchee
>>National Forest (landuse=forest and US National forests again)
>><https://www.mail-archive.com/talk-us@openstreetmap.org/msg16713.html>"
>>discussion a few months ago)
>>
>> as described on US Forest Service Data wiki page
>> <https://wiki.openstreetmap.org/wiki/US_Forest_Service_Data#National_Forest_Boundaries>.
>>
>>
>> The members of this super-relations would have their own tags either
>> normalized to the same values above the super-relation (maintaining
>> additional parcel-specific details) or would have their duplicative tags
>> removed. In particular, the boundary=national_park tag would be be
>> normalized to boundary=protected_area and the landuse=forest tag would
>> generally be removed.
>>
>> I'm planning to do all of this cleanup manually sometime soon and just
>> wondered if anyone had any further suggestions. I guess an alternative
>> process would be to reimport the parcel boundaries from the latest "Survey
>> Boundaries maintained by the US Forest Service
>> <https://data.fs.usda.gov/geodata/edw/datasets.php>" file, but I'm not
>> sure if that might be more difficult or easier.
>>
>> Thanks for any input!
>> Adam
>>
>> https://www.openstreetmap.org/user/Adam%20Franco
>>
>> ___
>> 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] Green Mountain National Forest cleanup

[Adam Franco]

Hello all,

I'm planning to do some cleanup of the Green Mountain National Forest in
Vermont and figured it might be useful to provide the opportunity for
feedback before embarking on this project.

The Green Mountain National forest is currently mapped as two large
outer-area relations that include large swaths of private land and many
ways and relations that mark independent parcel boundaries -- the latter
having a multitude of tag schemes.

Outer area boundaries:

   - northern section: https://www.openstreetmap.org/relation/2030450
   - southern section: https://www.openstreetmap.org/relation/1610349

Many parcel boundaries (examples):

   - https://www.openstreetmap.org/relation/6850907#map=13/44.0444/-73.0668
   - https://www.openstreetmap.org/relation/6631735#map=12/44.0070/-72.9569
   - https://www.openstreetmap.org/way/116060714#map=12/44.0123/-72.9418
   - 

There is very little consistency in the tagging of the parcel boundaries --
many are tagged as boundary=national_park, others are tagged as
boundary=protected_area. As well, many [most?] are tagged with
landuse=forest even if they are sensitive areas (protected watersheds),
wilderness areas (no logging allowed ever), designated recreation areas, or
otherwise not open to logging.

I propose to group all of the parcel boundaries into two super-relations,
one for the northern half of the GMNF and one for the souther half of the
GMNF. These super-relations would have:

   - type =boundary
   
   - boundary =
   protected_area
   
   - protect_class =6
   - protection_title
   =National
   Forest
   - protected 
   =perpetuity
   - operator =United
   States Forest Service

   - leisure=nature_reserve (this seemed to be recommended in the
"Okanogan-Wenatchee
   National Forest (landuse=forest and US National forests again)
   "
   discussion a few months ago)

as described on US Forest Service Data wiki page
.


The members of this super-relations would have their own tags either
normalized to the same values above the super-relation (maintaining
additional parcel-specific details) or would have their duplicative tags
removed. In particular, the boundary=national_park tag would be be
normalized to boundary=protected_area and the landuse=forest tag would
generally be removed.

I'm planning to do all of this cleanup manually sometime soon and just
wondered if anyone had any further suggestions. I guess an alternative
process would be to reimport the parcel boundaries from the latest "Survey
Boundaries maintained by the US Forest Service
" file, but I'm not sure
if that might be more difficult or easier.

Thanks for any input!
Adam

https://www.openstreetmap.org/user/Adam%20Franco
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Potential data source - NY DEC points of interest

[Adam Franco]

Hello all,

After doing a bit of hiking and canoeing in the Adirondacks this summer I
noticed that OSM has very poor coverage of campsites & lean-tos, something
I'd find particularly useful. The New York DEC POI shapefile
 has the
locations and details of these available and regularly updated.

Before going down the road of putting together an import proposal I wanted
to find out if anyone has information about usage grants for the DEC data
sets. From following this list I've heard that Kevin Kenny has imported
other DEC lands shapefiles for the park and area boundaries:
https://lists.openstreetmap.org/pipermail/talk-us/2016-May/016290.html

Do you Kevin [or anyone else] know if permission to use DEC lands also
applies to other DEC data sets or if additional permission would be needed?

I've added an entry about this data souce to the OSM Wiki's Potential
Datasources page
 and
would like to update it with more concrete information either from
usage-grants already received or by making a new request to use the data.

Any info or feedback on this datasource would be appreciated.

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

Re: [Talk-us] mapRe: (Second attempt) Potential data source: Adirondack Park Freshwater Wetlands

[Adam Franco]

Kevin, as a Vermont resident who is planning several canoe and hiking trips
to the Adirondacks (with data collection for OSM), I look forward to having
this import as context. Especially when exploring the Saint Regis canoe
wilderness, which has a few lakes in OSM, but is otherwise pretty devoid of
any sort of detail. Thanks for doing this work!

Best,
Adam

On Sat, Mar 26, 2016 at 9:58 AM, Kevin Kenny  wrote:

> On 03/26/2016 02:06 AM, Russ Nelson wrote:
>
>> Frederik Ramm writes:
>>   > I have zero knowledge about the Adirondack[s]
>>
>> I live here. Imagine a park half the size of Austria, with about 130K
>> people living in it, and 200K people visiting it. Give about 30K of
>> those people Internet access. Oh, and there are practically no nerds
>> living in the park, because there are no high-tech jobs.
>>
>> It's unlikely that anybody will do much in the Adirondacks whether
>> there's an import or not. If there's an import, at least there will be
>> something. Something is better than nothing, because at least it's
>> less wrong.
>>
>> Just do the import, Kevin.
>>
>> I do see an emerging consensus here, and Frederik (to whose opinion I
> ordinarily defer) appears to be something of an outlier. I do plan to
> go ahead with this, with appropriate warnings, wikification, and a
> quick request to the APA's GIS coordinator to confirm that we have
> permission to import (we do already, but I want to get the specific
> plan blessed).
>
> It may be some time in coming. Those who know me know that I'm pretty
> obsessive about data quality. This job is extremely likely to be a
> three-way conflation: what's already there (which, it appears, is
> mostly a 'lakes and ponds' file that you imported), the APA data set,
> and NHD. Each source has its unique properties.
>
> What's already there has all the tagging that mappers have done - and
> must not be damaged! Nevertheless, there simply is not much in OSM for
> the Adirondacks. I'm really working with a big blank spot in the map
> here!
>
> NED has the greatest detail (it was digitized at 1:24000 scale or
> finer, for the most part) and has the GNIS names of features. It also
> has feature classes that nothing else has, such as rapids, artificial
> shorelines, flumes, and so on. Its chief drawback is that there are
> objects that are unaccountably missing, in such a way that I suspect a
> database glitch happened at the USGS. For instance, the Cedar River
> Flow, a fairly sizable lake impounded by the Wakely Dam, is not in
> NHD - but the river becomes an 'artificial path' there, which is
> typically a flow line drawn through an area feature to keep the flow
> lines contiguous.
>
> The wetlands inventory lacks feature names, and is less detailed (it
> was digitized from orthophotos at 1:4 scale), but has many ponds
> and streams that NHD misses. It also has the intermittent or ephemeral
> water limits of many waterbodies. In the Adirondacks, these are
> important to a hiker. Many trails go through beaver meadows. In years
> when the beavers are in residence, the trails may be underwater, and
> the hiker must find a route around the pond. Having the high-water
> extent mapped is valuable information. The streams that it identifies,
> in the few places that I've checked, are there in the field. Alas, it
> does not have flowline topology, so conflation with NHD will need a
> little bit of patching.
>
> One bright spot is that the three data sets are well aligned (once the
> differences in datum are accounted for). A simple collision check
> identifies areal features to conflate. There may be a tiny bit of
> manual work for a few places (Indian Lake/Lewey Lake; Long Lake/Park
> Lake; Kiwassa Lake/Oseetah Lake/Lake Flower, and so on) where the
> boundaries between lakes are indefinite, in that you can take a canoe
> from one to another without noticing that you are on a 'different'
> lake.
>
> I'm still working on appropriate heuristics for conflating the linear
> features (flowlines, mostly). Again, I have the advantage that there
> is very little already in OSM to collide with - at most a few dozen
> rivers. What may turn out to be easiest is simply to lift the tags off
> the OSM features and apply them to the NHD ones.
>
> Then there's the area surrounding Duck Hole, which was permanently
> changed in Hurricanes Irene and Lee. Now that there is a few years'
> worth of orthophoto data available in all seasons, I think the best
> thing we could do there is to trace the shoreline from the orthophotos
> and add notes that our data reflect the shoreline and river channel
> from after the failure of the dam.
>
> Whatever I do, I plan to leave the features in OSM tagged with enough
> information to identify data provenance. This would mean, at the very
> least, NHD reachcode and permanent ID, APA object ID, and NWI label,
> where these are known, together, of course, with whatever tagging is
> present on the features that are already there.
>
> 

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[Adam Franco]

>
> Anybody up for writing a quick-and-dirty "here's how to develop an OSM
> renderer from scratch" wiki?  (Maybe I just haven't seen this if it already
> exists).  It may not be drop-dead easy, but an intermediate coder should be
> able to make one in short order (weeks, not months).


I would love to volunteer to test and validate any instructions that folks
are able to write as well as provide editing and feedback.

I wrote and maintain a project called Curvature
 that analyses the
geometry of highways in the OSM data set and outputs overlays that
motorcyclists and others can use to find the most twisty roads to
ride/drive. One of the biggest hurdles to this project has been the lack of
highway-surface data in most of the US and I'd love to put together a
renderer that colors highways based on their surface=* tags, highlighting
those that are missing the tag. I've been generating this data for myself
as KML files (like this example
)
but the tool-chain is a bit too long and updates are too delayed for broad
usage by the public.

Best,
Adam

On Tue, Nov 10, 2015 at 12:52 PM, stevea  wrote:

> Richard Welty wrote:
>
>>  the key thing, i think, is that mappers have little motivation to
>>  work on route relations if they don't actually get used by
>>  anything.
>>
>
> This is so, so true.  Not just about route relations, but in the general
> sense of "crowdsourced data SHOULD become visible by at least one renderer"
> whether an amenity=cafe node on mapnik, a new bicycle route on
> OpenCycleMap, freshly-defined (and tagged) rail infrastructure on
> OpenRailwayMap, AND route relations.
>
> Renderers must be rather tightly coupled to the data they display: it can
> be challenging for OSM to receive quality data without a decent renderer
> displaying those data.  The more quality renderers we have, specific to
> their subset of displayed data, the better our data will become -- with as
> many renderers as we care to develop.  OSM is multi-dimensional in this
> sense, and we can certainly walk and chew gum at the same time.
>
> The point is that these "other" renderers provide this motivation for
> mappers interested in their specific subset of tagging, beyond what shows
> up on mapnik.  Sure, novice mappers get excited to see the reward of their
> newly-added cafe node "blossom" on mapnik within a minute (or a few) thanks
> to fast tiling.  And we who map bicycle routes or rail infrastructure have
> gotten used to waiting for the minor delays (hours, a few days) it might
> take for renderers specific to OUR data to display our recent edits.
>
> But to encourage volunteer editors to crowdsource OTHER data (addresses,
> better route relations) into OSM, -- which do not now readily render -- a
> nearly fundamental requirement is for a renderer to display those results.
> These can be comprehensively managed volunteer efforts (OpenCycleMap,
> OpenRailwayMap), they can be something like the ItoWorld renderings, they
> can be a "sandbox" renderer like what Phil mocked up for highway shields.
> But to gin up a renderer and keep it functioning, fed and cared for
> shouldn't be so difficult or mysterious.  Our national chapter (OSM-US)
> might take some initiative here, or it might coordinate parceling out such
> efforts to interested regional parties.  Let's both discuss and better
> manage these efforts.
>
> Anybody up for writing a quick-and-dirty "here's how to develop an OSM
> renderer from scratch" wiki?  (Maybe I just haven't seen this if it already
> exists).  It may not be drop-dead easy, but an intermediate coder should be
> able to make one in short order (weeks, not months).
>
> 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] Best iOS app for GPS wander, GPX to laptop into OSM?

[Adam Franco]

For trail surveys and other GPS recording on Android I've been very happy
with Google's "My Tracks" app:
https://play.google.com/store/apps/details?id=com.google.android.maps.mytracks=en

It's pretty easy to use just hit "record", then allows the addition of
markers & photos while recording -- though I have only used markers myself.
After one is done recording, the track can be exported as a GPX file and
then sent to a computer via USB/Bluetooth/Dropbox or any other transfer
method enabled on your phone.

I've also tried doing surveys with OsmAnd, but found that the recording was
much less stable and would often get interrupted and need to be restarted
-- quite frustrating.

Adam

On Tue, Oct 6, 2015 at 8:05 AM, Greg Troxel  wrote:

>
> Marc Gemis  writes:
>
> > Keypadmapper can send the recorded data via email.
>
> Keep in mind that keypadmapper is spyware :-) In all seriousness, it
> uploads locations and cell ids to a public database whenever it's
> running.  If you're out explicitly doing mapping, that might be fine at
> times, but it's bad behavior in general and I must therefore recommend
> against recommending 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

Re: [Talk-us] Best iOS app for GPS wander, GPX to laptop into OSM?

[Adam Franco]

As far as I can tell, MyTracks is a super-simple application that doesn't
seem like it would introduce any Google IP -- though maybe you or others
have better ideas of how such a thing might occur. I've never seen a track
snap to roads or trails (all of the GPX track-points seem to have the
standard GPS offset/errors introduced by terrain/poor-fix/etc) and it
doesn't do routing or provide any external data other than displaying
Google Maps/Satellite tiles as a display underlay when viewing the track in
the application.

On Tue, Oct 6, 2015 at 12:10 PM, Simon Poole <si...@poole.ch> wrote:

> Besides having all the issues Keypadmapper has squared, how do you prevent
> IP leakage from google to OSM? For example do you know if it employs any
> "lock on road" or similar technology?
>
> Simon
>
>
> Am 06.10.2015 um 17:47 schrieb Adam Franco:
>
> For trail surveys and other GPS recording on Android I've been very happy
> with Google's "My Tracks" app:
>
> https://play.google.com/store/apps/details?id=com.google.android.maps.mytracks=en
>
> It's pretty easy to use just hit "record", then allows the addition of
> markers & photos while recording -- though I have only used markers myself.
> After one is done recording, the track can be exported as a GPX file and
> then sent to a computer via USB/Bluetooth/Dropbox or any other transfer
> method enabled on your phone.
>
> I've also tried doing surveys with OsmAnd, but found that the recording
> was much less stable and would often get interrupted and need to be
> restarted -- quite frustrating.
>
> Adam
>
> On Tue, Oct 6, 2015 at 8:05 AM, Greg Troxel < <g...@ir.bbn.com>
> g...@ir.bbn.com> wrote:
>
>>
>> Marc Gemis <marc.ge...@gmail.com> writes:
>>
>> > Keypadmapper can send the recorded data via email.
>>
>> Keep in mind that keypadmapper is spyware :-) In all seriousness, it
>> uploads locations and cell ids to a public database whenever it's
>> running.  If you're out explicitly doing mapping, that might be fine at
>> times, but it's bad behavior in general and I must therefore recommend
>> against recommending it.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
> ___
> 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
>
>

On Tue, Oct 6, 2015 at 12:10 PM, Simon Poole <si...@poole.ch> wrote:

> Besides having all the issues Keypadmapper has squared, how do you prevent
> IP leakage from google to OSM? For example do you know if it employs any
> "lock on road" or similar technology?
>
> Simon
>
>
> Am 06.10.2015 um 17:47 schrieb Adam Franco:
>
> For trail surveys and other GPS recording on Android I've been very happy
> with Google's "My Tracks" app:
>
> https://play.google.com/store/apps/details?id=com.google.android.maps.mytracks=en
>
> It's pretty easy to use just hit "record", then allows the addition of
> markers & photos while recording -- though I have only used markers myself.
> After one is done recording, the track can be exported as a GPX file and
> then sent to a computer via USB/Bluetooth/Dropbox or any other transfer
> method enabled on your phone.
>
> I've also tried doing surveys with OsmAnd, but found that the recording
> was much less stable and would often get interrupted and need to be
> restarted -- quite frustrating.
>
> Adam
>
> On Tue, Oct 6, 2015 at 8:05 AM, Greg Troxel < <g...@ir.bbn.com>
> g...@ir.bbn.com> wrote:
>
>>
>> Marc Gemis <marc.ge...@gmail.com> writes:
>>
>> > Keypadmapper can send the recorded data via email.
>>
>> Keep in mind that keypadmapper is spyware :-) In all seriousness, it
>> uploads locations and cell ids to a public database whenever it's
>> running.  If you're out explicitly doing mapping, that might be fine at
>> times, but it's bad behavior in general and I must therefore recommend
>> against recommending it.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
> ___
> 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] Importing highway surface tags

[Adam Franco]

Thank you all for the great feedback and advice! It looks like this project
is potentially feasible but that I have many things to learn and figure out
to make it happen. I'll be in touch after I've figured out how to work with
the VCGI data and then get proper usage permission. Thanks again and happy
holidays!

Best,
Adam

On Fri, Dec 21, 2012 at 9:47 AM, Andrew Guertin andrew.guer...@uvm.eduwrote:

 On 12/20/2012 05:03 PM, Adam Franco wrote:
  * Has anyone located a good source for state or national road surface
 data?
  The TIGER data doesn't seem to include surface information as far as I
 can
  tell.

 The VCGI EmergencyE911_RDS file has a field for this. Unfortunately,
 58773 out of 64302 values (91%) are Unknown.

 The VCGI license doesn't explicitly give the permissions needed for OSM,
 but when I asked to use the town boundaries layer they gave permission.
 (I still need to get around to that...)

  * Is this a project that the OSM community in Vermont, the broader
 region,
  or nationally (assuming data is available) would support? I'd rather not
 do
  a lot of work to prepare it if there is no desire for inclusion in the
 data
  set.

 I'd support it.

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

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

[Talk-us] Importing highway surface tags

[Adam Franco]

Hello All,

I'm pretty new to the OSM community and have gotten involved through a
hobby project analyzing road
geometrieshttps://github.com/adamfranco/curvature/wiki.
I live in Vermont, a state where more than half of the road-miles are
unpaved graded-gravel. For the benefit of my project and hopefully the OSM
community I have been working outward from my home tagging highway
surfaceshttp://www.openstreetmap.org/user/Adam%20Franco/editsas
gravel, asphalt, or concrete based on direct observation as well as
looking at high-resolution aerial imagery where available.

What I am interested in doing is bulk-tagging the surface of roads based on
public data where no surface tag has been manually set. Before I begin this
project (and pester my department of transportation for data) I wanted to
check with the community about the permissibility and feasibility of this
effort.

A few questions:

* Has anyone located a good source for state or national road surface data?
The TIGER data doesn't seem to include surface information as far as I can
tell.

* While the devil is always in the details, I'm assuming that a relatively
safe import could be done by only adding tags to ways that don't have
surface tags already. Are there other considerations I should be thinking
about related to not worsening the OSM data?

* Is this a project that the OSM community in Vermont, the broader region,
or nationally (assuming data is available) would support? I'd rather not do
a lot of work to prepare it if there is no desire for inclusion in the data
set.

Thank you for your feedback,
Adam
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us