Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Skyler Hawthorne]

Thank you so much for your reply! That's exactly the kind of insight I was 
hoping for by posting here.


On July 16, 2020 12:16:19 Kevin Kenny  wrote:


I'm less sanguine than Skyler is about the data quality.  I suspect
s/he (the given name doesn't clearly identify a preferred pronoun) has
been looking at urban or suburban areas in counties whose GIS
departments have relatively stable funding. In those situations, yes,
the data are fairly good.  There is still a serious conflation issue
that isn't addressed, with respect to buildings whose footprints are
already mapped but do not bear addresses, where the address point may
or may not be in the building footprint.  Many address points, too,
get clustered at the entrance of a private or shared driveway, rather
than being on the indivdual dwellings. I seem to recall that at least
one or two of the apartment and townhouse complexes in the general
area of https://www.openstreetmap.org/#map=18/42.83211/-73.89931 had
to have their house numbers collected on foot, because the E911 data
showed all the address points in a single cluster.

In the rural areas, particularly in the counties with tiny
populations, the situation is grimmer. I'm not certain that Schuyler
or Wyoming Counties even would _have_ dedicated GIS departments!
Until relatively recently, when grant money was available to have this
information in GIS systems for E911 use, they mostly were still using
paper maps, often referenced to an unknown datum.  (The first job in
dealing with any scanned tax plat is figuring out what coordinate
frame it's using - around here, NAD27 differs from NAD83 by a few tens
of metres.) The address points may be parcel centroids, or building
centroids, or the point where the driveway meets the road, or even
just something that was digitized from a pencil sketch made by an
assessor.  Import of this sort of data could well prove to be a
short-term gain but impose a heavy long-term burden; consider the
love-hate relationship that we all have with TIGER. (The import means
that we've got a nearly-filled-in map, a lot of which is of
halfway-decent quality, and we don't have the mappers to have done it
nearly as quickly any other way. Nevertheless, for some years we've
been paying the price in bad data and worse conflation.)

So, my advice for both legal and technical reasons would be to use
caution, and recognize that mechanical import is likely to be a
disaster - the data will need to be eyeballed by human beings and
corrected.


I certainly did not do an extensive check of the quality, so this is a 
super useful perspective. (I wanted more clarity on the legal aspect before 
investing more time in that, since, after all, if it's a definite no go 
from a legal perspective, why waste any time at all?) It's unfortunate that 
there's such a big variation in quality, although not unexpected, since 
they come from the counties themselves.


However, at least the examples you gave would not necessarily make me 
consider the data unusable without extensive correction. The way I look at 
this is: if the point is close enough that were a person to stand right at 
the exact spot, could they find the place they are looking for? If the 
answer is yes for the vast majority of the data, then I would call that a 
net gain for OSM.


Furthermore, if the data were never manually reviewed and corrected, would 
it still be valuable enough to import? You obviously have extensive 
experience with this data set, so I would trust your judgment on this, but 
if the worst problems we see are mostly the ones you described, it would 
sound to me like the pros outweigh the cons, even if the points were never 
corrected.


For example, I've personally seen many roads from TIGER imports that are 
way way off, or even nonexistent, especially long driveways in deeply rural 
areas. But the fact that the main named roads are there at all is a huge 
benefit to OSM, even if not every road is perfectly accurate, and many will 
simply never be reviewed.


(With that said, obviously I would want the data to be as accurate as 
possible, and I'm not making a case to import all the data as is with no 
review or correction, but simply thinking through the practical reality of 
the task of making all the data completely accurate. We don't want perfect 
to be the enemy of good.)


For the issue of conflation with existing buildings with no address tags, 
that might be too difficult of a case to address without reviewing each and 
every case by hand, which might be practically infeasible. I've seen a lot 
of cases where there is a house and a detached garage, or in-law right next 
to the house. It might be possible to detect if there is only one point 
that is inside of a building, but for the other cases you mentioned, where 
it might instead be the centroid of the parcel, or at the intersection of 
the driveway and the street, I don't think there would be a way around 
fixing these by hand, which indeed would be 

Re: [Talk-us] [OSM-talk] private or not, USA ?

[Steve Friedl]

Answering a different question than what you asked: they don’t belong in OSM, 
so any other answer is off topic.

 

Right?

 

Steve

 

--- 

Steve Friedl // Software guy + Volunteer mapper // Southern California USA

st...@unixwiz.net [OSM:SJFriedl] // OpenStreetMap MWG //  Fix ALL the maps!

 

 

From: 80hnhtv4agou--- via talk  
Sent: Thursday, July 16, 2020 5:59 PM
To: talk-us@openstreetmap.org; t...@openstreetmap.org
Subject: [OSM-talk] private or not, USA ?

 

Are wi-fi passwords and the IP number of a hot spot, located in MC Donald, 
burger-king, Starbucks,

 

motel 6, super 8, best western ect. public ?

 

 

 

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

[Talk-us] private or not, USA ?

[80hnhtv4agou--- via Talk-us]

Are wi-fi passwords and the IP number of a hot spot, located in MC Donald, 
burger-king, Starbucks,
 
motel 6, super 8, best western ect. public ?
 
 
 ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Clear Creek County in Colorado has a broken county boundary

[Taylor Smock]

https://data.colorado.gov/Transportation/Counties-in-Colorado/67vn-ijga

The `About` tab /claims/ that the data is Public Domain, but I would
double check, just in case. (Some people I've talked to in county
governments thought public domain meant the data was available for the
public, /not/ that the copyright status was public domain, so I've
learned to double check).

On 7/16/20 12:28 PM, stevea wrote:
> If any Colorado or Rocky Mountain area mappers know where data may be 
> acquired to fix some missing segments in the boundary of Clear Creek County 
> (relation/442310), I ask that they either be pointed to or that those data 
> please be repaired.
>
> 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] Coconino National Forest boundary isn't rendering anymore?

[stevea]

To my reply of:
>> Coconino's boundary IS rendering, but with more accurate tags, and 
>> differently than a national_park

Joseph Eisenberg  wrote:
> 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

I appreciate the clarification, and now better understand that there is an 
issue with a particular multipolygon not rendering in Carto.  I also now 
understand that these are intended to render identically from two different 
sets of tags, one set that was previously applied to this multipolygon, one set 
that is presently applied to this multipolygon.

I also apologize for my misunderstanding.

As the issue seems to be "at the highest zoom levels" (where I assume it wasn't 
before), I defer to the authors of the renderer code to determine what the root 
cause may be.

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

[Talk-us] Clear Creek County in Colorado has a broken county boundary

[stevea]

If any Colorado or Rocky Mountain area mappers know where data may be acquired 
to fix some missing segments in the boundary of Clear Creek County 
(relation/442310), I ask that they either be pointed to or that those data 
please be repaired.

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]

>  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?

[stevea]

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] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Once you write this diary entry (or OSM Wiki page) please post
it to the mailing list!

Jul 16, 2020, 18:15 by kevin.b.ke...@gmail.com:

> (It got fixed.)  Mateusz, do I recall that you took part
> in the reversion?
>
No, but I was working on much simpler deimport:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them

Still, it took plenty of time to do it properly and for years OSM had 
many misleading POIs because import was not done properly.

Though note that it was import from OSM prehistory (2009),
when issues related to imports were not known well.

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

[Talk-us] OpenStreetMap US Applies to Become Official OSMF Local Chapter

[Maggie Cawley]

OpenStreetMap US is excited to announce that we have applied to become an
official Local Chapter of the OpenStreetMap Foundation
. OSM US was founded in
2010 to hold the first annual State of the Map US. Over the past 10 years,
our community has actively contributed to the global community and grown
alongside the project.

Community is the backbone of OpenStreetMap. OSM US believes that becoming a
formal Local Chapter will be a positive step forward for the organization
and our community. Last year, OSM US revived conversations with the OSMF to
become a formal Local Chapter. Thanks to the work and patience of the OSMF
and OSM US Board members, we were able to adapt the Local Chapter Agreement
to the needs of the community in the United States in the form of a revised
agreement that we hope can also benefit other Local Chapters around the
world. OpenStreetMap US has since submitted our application documents, and
the application will be open to public comment in the coming weeks. You can
read more about the process here.


OpenStreetMap US looks forward to the next chapter and working more closely
with other Chapter leaders and the OSMF to collaboratively grow and support
the OpenStreetMap community, as an official Local Chapter.

Have questions or comments? We’d love to hear from you. Reach out via Slack
 or send an email to t...@openstreetmap.us.
Read more here: https://www.openstreetmap.us/2020/07/osmuslocalchapter/


*Maggie Cawley*
Executive Director
OpenStreetMap US
www.openstreetmap.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

[Kevin Kenny]

(By the way, hi, Skyler, and welcome!  You've stepped into a difficult
area - most programmers don't realize just how difficult until they've
waded in.

The legal situation in New York is _very_ complicated, because the key
court case that governs GIS data settled out of court before the
underlying issues were resolved. You simply will not ever get a clear
statement about the legalities, because, alas, there was a court case
that left a door open a tiny crack - and then never reached a judgment
because the parties settled on undisclosed terms.  The only people who
could actually cut through the weeds at this point would be the Court
of Appeals for the Second Circuit.  Copyright litigation is ruinously
expensive, and neither the agencies who would have a purported
interest in the data nor any user has the means to pursue a copyright
case that far.

I've been asked this question enough that it deserves a more
comprehensive answer.  I probably will write at greater length over
the weekend and put the results in an OSM diary entry and blog post,
and come back here to link to them.

My personal belief, with which OSM's legal team may or may not agree
(with that said, there's never any certainty in the law!) is that New
York's open government law renders the use of the data pretty much
fair game from the legal perspective.

This data set has a  complex history.  It was produced because there
were grants offered to prepare a geocoding system for E911 use. The
address points used to support this effort, for the most part, did not
originate in the state's GIS office, but instead were provided by the
counties. The role of NYSGIS was to coordinate the efffort, to pass
grant money through to local governments, and to normalize and adapt
the data, in some cases to anonymize, and to conform the data to
national standards (https://nena.org/). When I've referred on the list
(or in changeset comments, etc.) to county E911 data in New York, I've
ordinarily been talking about exactly this data set.

I use it routinely, but only as a source of address data when I'm
tracing buildings; in my town. It's usable for that when taken with a
grain of salt and backed up with field survey for items that look
questionable (e.g., the addresses of all buildings in a subdivision or
apartment complex sharing a single point).  I do field surveys only
afoot, so I'm somewhat limited in how far from home I've been ready to
map, but you can see the results in the general area of
https://www.openstreetmap.org/#map=16/42.8213/-73.8833. I'm confident
that my use steers clear of copyright issues in any case. I'm making
my own selection of the data with significant revisions, so the
"selection, sequence and arrangement" of the data are not even similar
to what is in the data set.  Essentially, all that I extract are bald,
individual facts. To assert that such extraction is a violation of
copyright is to advance a 'mental contamination' theory, and would
disqualify most mappers from ever mapping anything, since it would
effectively mean that if you'd ever seen anything in a commercial data
set, you couldn't map that object even if you verified it
independently. (There are copyright maximalists who have attempted to
advance just that sort of claim.  The US pretty much shot them down in
Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340
(1991) 
https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.>
The solution in the UK and Australia is murkier, and does verge on the
"mental contamination" theory.) Moreover, the purpose of the database
is to enable both governments and NGO's to have access to the
geocoding for emergency response. Asserting copyright against OSM for
use of E911 data would almost certainly be held to go against sound
public policy.

I'm less sanguine than Skyler is about the data quality.  I suspect
s/he (the given name doesn't clearly identify a preferred pronoun) has
been looking at urban or suburban areas in counties whose GIS
departments have relatively stable funding. In those situations, yes,
the data are fairly good.  There is still a serious conflation issue
that isn't addressed, with respect to buildings whose footprints are
already mapped but do not bear addresses, where the address point may
or may not be in the building footprint.  Many address points, too,
get clustered at the entrance of a private or shared driveway, rather
than being on the indivdual dwellings. I seem to recall that at least
one or two of the apartment and townhouse complexes in the general
area of https://www.openstreetmap.org/#map=18/42.83211/-73.89931 had
to have their house numbers collected on foot, because the E911 data
showed all the address points in a single cluster.

In the rural areas, particularly in the counties with tiny
populations, the situation is grimmer. I'm not certain that Schuyler
or Wyoming Counties even would _have_ dedicated GIS departments!
Until relatively recently, when grant 

Re: [Talk-us] sweat of the brow & sui generis database rights | Re: Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

16 Jul 2020, 16:33 by r...@technomancy.org:

> On 16/07/2020 13:35, Russell Nelson wrote:
>
>> As you say, it's just a listing of facts about the world. At most the 
>> presentation of them is copyrightable, but as Skyler noted, he's changing 
>> the presentation.
>>
>> No license needed for facts.
>>
>
> Remember, that might the law in the USA, but not in the whole world, 
> including the UK, where (lots of) the OSM servers & legal body is based, 
> which can have the  “sweat of the brow” doctrine, rather than the higher  
> “creativity” requirement. In addition, many countries (incl. EU & UK) have 
> “sui generis database rights”, which give copyright like protections to 
> collections of facts. OSM uses that legal protection.
I am not a lawyer, but I am pretty sure
that it is not relevant to the data published
by New York State (that was produced 
in US jurisdiction).

> Regardless, OSM is not a forum to explore the grey areas of international 
> copyright law. If we're not sure, we don't use it! 
>
+1, but hopefully with some research we
may becone sure what is the legal situation___
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

[Jmapb]

HI Skyler, I'm also a NY mapper, welcome to the party!

You've probably gleaned by now that imports are a touchy subject in OSM.
Data license is part of the problem, since only the very most open of
open licenses are compatible with OSM. My assumption is that the NYS
address data will pass this test, but then there are additional
questions of accuracy, transformation, maintainability, and conflation
with the existing data.

One thing that jumps out right away -- importing addresses for all of NY
state is a gargantuan task. Most address imports on OSM will center
around a small area, maybe as large as a county, and even so the task
will generally be broken up into even smaller areas using a tasking
manager and imported gradually by a team, with a lot of manual scrutiny.
An address import for all of NY State would likely be a years-long,
project.

I also expect that data quality, both location and the address fields,
will vary in the extreme. There may be some portions of the state where
the data is entirely useless, or will do more harm than good. And
unfortunately, without local knowledge to consult, it can be difficult
to determine this ahead of time.

My advice would be to sketch out an import plan for a small community
you're familiar with, and see how that goes. You'll probably find that
some common assumptions about addresses are false at the edge cases. For
instance, you mention deduplicating by searching for existing elements
with matching addr:* tags. But I've frequently found a single address
applying to several buildings/properties, and the converse too of
course. Having different roads with the same name in close proximity is
also alarmingly common. Expect mismatches due to variance in street
names (Campbel Lane, Camp Bell Road, etc.)  or addresses currently
mapped with only a housenumber.

There are also many areas in NY where we have buildings mapped without
address tags. Ideally we'd want to add the address tags to the building
where appropriate, rather than just plop a new node somewhere in the
building's vicinity. This would almost certainly take a lot of manual
tweaking.

It's an exciting prospect to have good address data for the large
portions of the state that are relatively unmapped. I'll be happy to
assist with this project in whatever form it takes. For now I'm still
mapping addresses the old-fashioned way, by reading the numbers off of
mailboxes and front doors.

Good luck, Jason


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

Re: [Talk-us] sweat of the brow & sui generis database rights | Re: Interested in importing address points in New York State

[Russell Nelson]

On 7/16/20 10:33 AM, Rory McCann wrote:

On 16/07/2020 13:35, Russell Nelson wrote:
As you say, it's just a listing of facts about the world. At most the 
presentation of them is copyrightable, but as Skyler noted, he's 
changing the presentation.


No license needed for facts.


Remember, that might the law in the USA, but not in the whole world, 
including the UK, where (lots of) the OSM servers & legal body is 
based, which can have the  “sweat of the brow” doctrine, rather than 
the higher  “creativity” requirement. In addition, many countries 
(incl. EU & UK) have “sui generis database rights”, which give 
copyright like protections to collections of facts. OSM uses that 
legal protection.



Context: New York State.



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

Re: [Talk-us] [Imports-us] Interested in importing address points in New York State

[Matthew Woehlke]

On 16/07/2020 00.44, Skyler Hawthorne wrote:
Reading up on the import guidelines, I can see that the license is 
important. However, I am not able to see anything that explicitly states 
one way or another what kind of license the data sets are distributed 
under, and this whether or not it is compatible with the ODBL.


Hello again! Great to see someone else working in my neck of the woods!

If the site doesn't state clearly (an issue I had with Prince William 
County, VA, which I have been working on for job-related reasons), I 
would recommend contacting the data issuing agency. I see it's a .ny.gov 
site, so it's almost surely legitimate (plus it's hard to imagine 
someone making the effort to set up a scam site with enough content to 
not be obvious).


There are some form letters you can use to ask if the data is available 
under a compatible license, or you can just ask them to clearly indicate 
the license *or if the data is Public Domain*. In my experience, it may 
be helpful to ask up front for the contact to clearly state if the data 
is or is not PD.


As a disclaimer, I do this in my free time, which is in short supply, so 
progress on this would likely be slow. However, I would love if everyone 
could just search for any address and find it.


As someone who recently went looking and discovered that his former 
residence "doesn't exist" in OSM, I for one will be most gratified to 
see any improvements in the area :-).


--
Matthew

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

[Talk-us] sweat of the brow & sui generis database rights | Re: Interested in importing address points in New York State

[Rory McCann]

On 16/07/2020 13:35, Russell Nelson wrote:
As you say, it's just a listing of facts about the world. At most the 
presentation of them is copyrightable, but as Skyler noted, he's 
changing the presentation.


No license needed for facts.


Remember, that might the law in the USA, but not in the whole world, 
including the UK, where (lots of) the OSM servers & legal body is based, 
which can have the  “sweat of the brow” doctrine, rather than the higher 
 “creativity” requirement. In addition, many countries (incl. EU & UK) 
have “sui generis database rights”, which give copyright like 
protections to collections of facts. OSM uses that legal protection.


Regardless, OSM is not a forum to explore the grey areas of 
international copyright law. If we're not sure, we don't use it! 



Rory

___
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
. 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  to
> the OpenStreetMap  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
>
>- vt-boundaries-all-lines
>
>- VT Hydrography Dataset
>
>- VT E911 Site Locations
>
> 
>
> I've read through the VCGI Warranty/Copyright document
> 
> 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 
> 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 there
> are any license restrictions to be aware of.
>
> [7] If you have any specific legal questions, the OpenStreetMap
> Foundation's License Working Group can be reached at
> le...@osmfoundation.org and will be glad to help.
>

And this is what I got back:

> -- Forwarded message -
> From: Adams, John E. 
> Date: Thu, Sep 21, 2017 at 10:34 

Re: [Talk-us] Interested in importing address points in New York State

[Alex Hennings]

Regarding: "No license needed for facts"
A reminder that the *collection *of facts is part of it's presentation, and
can have copyright protection. You'd be creating a derivative work. This is
what protects recipe books, maps, and dictionaries. I'm not a lawyer.

On Thu, Jul 16, 2020 at 7:37 AM Russell Nelson  wrote:

> On 7/16/20 5:26 AM, Mateusz Konieczny via Talk-us wrote:
> > On the other hand, it may be unoriginal database... Still, the
> > preferred version is to have an explicit
> > license.
>
> I tried getting some acknowledgement from New York State GIS that their
> data was not copyrighted or not copyrightable back when I imported the
> NYSDEC lands shapefile. The most I could get out of them was that they
> don't claim a copyright. I had saved that email thread on my Cloudmade
> laptop. After I got laid off and had to send the laptop back, I didn't
> think to save that email.
>
> As you say, it's just a listing of facts about the world. At most the
> presentation of them is copyrightable, but as Skyler noted, he's
> changing the presentation.
>
> No license needed for facts.
>
>
>
> ___
> 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?

[stevea]

 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] Interested in importing address points in New York State

[Russell Nelson]

On 7/16/20 5:26 AM, Mateusz Konieczny via Talk-us wrote:
On the other hand, it may be unoriginal database... Still, the 
preferred version is to have an explicit

license.


I tried getting some acknowledgement from New York State GIS that their 
data was not copyrighted or not copyrightable back when I imported the 
NYSDEC lands shapefile. The most I could get out of them was that they 
don't claim a copyright. I had saved that email thread on my Cloudmade 
laptop. After I got laid off and had to send the laptop back, I didn't 
think to save that email.


As you say, it's just a listing of facts about the world. At most the 
presentation of them is copyrightable, but as Skyler noted, he's 
changing the presentation.


No license needed for facts.



___
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

[Dave Swarthout]

There is a very experienced OSM mapper who has extensive knowledge of NYS
databases. He is Kevin Kenny and his OSM email is
kevin.b.kenny+...@gmail.com

I'm pretty sure he will know something about copyright issues. I supply his
email because I'm not sure if he monitors this list.

On Thu, Jul 16, 2020 at 4:28 PM Mateusz Konieczny via Talk-us <
talk-us@openstreetmap.org> wrote:

>
> Jul 16, 2020, 06:44 by o...@dead10ck.com:
>
> I found that NYS publishes GIS data in their "Clearing House", and one of
> the data sets available is address points:
> https://gis.ny.gov/gisdata/inventories/details.cfm?DSID=921
>
> I opened the data in JOSM, and they look spatially accurate, for the most
> part (I noticed some points are off for addresses that don't have recent
> satellite imagery available).
>
> Reading up on the import guidelines, I can see that the license is
> important. However, I am not able to see anything that explicitly states
> one way or another what kind of license the data sets are distributed under
>
> Hello and thanks for checking before the import!
> License is important, sadly it seems to not be specified anywhere.
>
> , and this whether or not it is compatible with the ODBL. I wanted to ask
> if perhaps anyone else had investigated these data sets in the past, and
> what their findings were. If not, is the next step to email someone and ask?
>
> I just looked at it and it seems that either it is not specified or I
> missed it.
>
> If nobody will be able to locate that info then emailing specified contact
> would be a good next step.
>
> Note
>
> https://en.wikipedia.org/wiki/Copyright_status_of_works_by_subnational_governments_of_the_United_States#New_York
>
> So unlike work of federal government it is not automatically public domain.
>
> On the other hand, it may be unoriginal database... Still, the preferred
> version is to have an explicit
> license.
>
> I don't have anything like an extensive plan for carrying out an import,
> which is why I did not include the "authoritative" imports mailing list
> yet. However, at a high level, as I am a software engineer by trade, my
> plan is to write a script that reads the shapefiles and an .osm file dump
> as input, does the attribute to tag transformations, and deduplicates with
> the existing data by excluding any address points that already exist in any
> OSM object with equivalent addr:* tags (it might also be necessary to
> inspect all associatedStreet and street relations). It would produce an
> .osm as output that contains nodes with just addr:* tags. This can then be
> opened in JOSM and merged into the standard data layer. I'd probably start
> with a single county and go from there.
>
> Similar things were done already so remember to check whatever existing
> tools for
> converting and conflation are good enough to use/modify rather than start
> from scratch.
>
> As a disclaimer, I do this in my free time, which is in short supply, so
> progress on this would likely be slow.
>
> Like OSM mapping in general.
>
> However, I would love if everyone could just search for any address and
> find it.
>
> +1
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
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

[Mateusz Konieczny via Talk-us]

Jul 16, 2020, 06:44 by o...@dead10ck.com:

> I found that NYS publishes GIS data in their "Clearing House", and one of the 
> data sets available is address points: 
> https://gis.ny.gov/gisdata/inventories/details.cfm?DSID=921
>
> I opened the data in JOSM, and they look spatially accurate, for the most 
> part (I noticed some points are off for addresses that don't have recent 
> satellite imagery available).
>
> Reading up on the import guidelines, I can see that the license is important. 
> However, I am not able to see anything that explicitly states one way or 
> another what kind of license the data sets are distributed under
>
Hello and thanks for checking before the import!
License is important, sadly it seems to not be specified anywhere. 

> , and this whether or not it is compatible with the ODBL. I wanted to ask if 
> perhaps anyone else had investigated these data sets in the past, and what 
> their findings were. If not, is the next step to email someone and ask?
>
I just looked at it and it seems that either it is not specified or I missed it.

If nobody will be able to locate that info then emailing specified contact 
would be a good next step.

Note
https://en.wikipedia.org/wiki/Copyright_status_of_works_by_subnational_governments_of_the_United_States#New_York

So unlike work of federal government it is not automatically public domain.

On the other hand, it may be unoriginal database... Still, the preferred 
version is to have an explicit
license.

> I don't have anything like an extensive plan for carrying out an import, 
> which is why I did not include the "authoritative" imports mailing list yet. 
> However, at a high level, as I am a software engineer by trade, my plan is to 
> write a script that reads the shapefiles and an .osm file dump as input, does 
> the attribute to tag transformations, and deduplicates with the existing data 
> by excluding any address points that already exist in any OSM object with 
> equivalent addr:* tags (it might also be necessary to inspect all 
> associatedStreet and street relations). It would produce an .osm as output 
> that contains nodes with just addr:* tags. This can then be opened in JOSM 
> and merged into the standard data layer. I'd probably start with a single 
> county and go from there.
>
Similar things were done already so remember to check whatever existing tools 
for
converting and conflation are good enough to use/modify rather than start from 
scratch.

> As a disclaimer, I do this in my free time, which is in short supply, so 
> progress on this would likely be slow.
>
Like OSM mapping in general.

> However, I would love if everyone could just search for any address and find 
> it.
>
+1

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

[Talk-us] Interested in importing address points in New York State

[Skyler Hawthorne]

Hello. I'm a relatively new mapper, and I'm mostly working in upstate NY, 
where there is not great coverage outside of roads. I've been adding houses 
manually, but progress is slow and inefficient this way.


I found that NYS publishes GIS data in their "Clearing House", and one of 
the data sets available is address points: 
https://gis.ny.gov/gisdata/inventories/details.cfm?DSID=921


I opened the data in JOSM, and they look spatially accurate, for the most 
part (I noticed some points are off for addresses that don't have recent 
satellite imagery available).


Reading up on the import guidelines, I can see that the license is 
important. However, I am not able to see anything that explicitly states 
one way or another what kind of license the data sets are distributed 
under, and this whether or not it is compatible with the ODBL. I wanted to 
ask if perhaps anyone else had investigated these data sets in the past, 
and what their findings were. If not, is the next step to email someone and 
ask?


I don't have anything like an extensive plan for carrying out an import, 
which is why I did not include the "authoritative" imports mailing list 
yet. However, at a high level, as I am a software engineer by trade, my 
plan is to write a script that reads the shapefiles and an .osm file dump 
as input, does the attribute to tag transformations, and deduplicates with 
the existing data by excluding any address points that already exist in any 
OSM object with equivalent addr:* tags (it might also be necessary to 
inspect all associatedStreet and street relations). It would produce an 
.osm as output that contains nodes with just addr:* tags. This can then be 
opened in JOSM and merged into the standard data layer. I'd probably start 
with a single county and go from there.


As a disclaimer, I do this in my free time, which is in short supply, so 
progress on this would likely be slow. However, I would love if everyone 
could just search for any address and find it.

--
Skyler



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