[talk-cz] Drobnosti na osmap.cz

2020-07-16 Per discussione Tom Ka
Ahoj, par drobnosti na webu osmap.cz (v0.27):

- ruzne drobnejsi opravy kodu (fotky Fody), URL map apod. (Mapbox API, LPIS)
- doplneny mapove vrstvy Maptiler.com (diky Jirko!)

vse na:
https://github.com/osmcz/osmcz/commits/production
https://github.com/osmcz/osmcz/compare/v0.26...v0.27

Konec hlaseni
tom.k

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


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

2020-07-16 Per discussione 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-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Jarek Piórkowski
On Thu, 16 Jul 2020 at 11:30, Andrew Deng via Talk-ca
 wrote:
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1) 
> should be tagged as highway=primary rather than highway=secondary as it is 
> tagged now.
> Here are some reasons I believe why:
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill, 
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
> 2) It is a major thoroughfare throughout the route. In Toronto, the Yonge 
> subway follows it and in York Region, Viva bus lanes are being built. It also 
> connects to Bradford in the north.> 3) It was a former Ontario King's Highway 
> - Highway 11. Some other former King's Highways in the Toronto/York area are 
> tagged as highway=primary, such as Highway 27, Highway 7, and Highway 48.

Hi Andrew, hi mailing list,

I've been thinking about this for a while. Thanks for bringing this up!

I'd like to contribute to a wider discussion about tagging primary in
Ontario, particularly in urban and suburban areas. I think we should
use it more - here's why.

I've been unhappy for a while with the tagging guidelines for Ontario
roads. The primary/secondary/tertiary OSM scheme originated in the UK,
where basically all "A-roads" are primary (or trunk) and all "B-roads"
are secondary. This is a UK-wide scheme and a crucial point is that
there are still A-roads in busy urban areas. For example what is by
GTA standards a narrow street in inner city like
https://osm.org/way/327282307 (one-way, 1 or at most 2 lanes) is
primary because it's an A road. [1] Many other regions in Europe also
use primary for urban thoroughfares with frequent cross streets.

For a long time, the Canadian tagging guidelines were a very close
copy of the UK scheme - check out Danny's wiki edit in May 2019 [2]
that removed very UK-like references to "C roads" (a UK
classification) and "a suburb" ("An example would be the main roads
within the suburb to get to the local primary school", "A
highway=residential road which is used for accessing or moving between
private residential properties (homes).  Otherwise called a
'suburb'."), and removed a statement that primary, secondary, and
tertiary roads are "all maintained by the provincial governments, with
provincial jurisdiction."

https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
still specifies that in Canada, a highway=primary is a "Provincial
primary highway that does not meet freeway standards". That might work
in BC, where there are provincial highways in downtown Vancouver, but
it doesn't work in Ontario. BC Highway 99 through downtown Vancouver
is tagged as trunk, and it is no wider than Yonge through York Region
tagged as secondary.

Historically, in Ontario, the maintenance and jurisdiction of a road
has more to do with whether a lower-level government could be
strong-armed into accepting ownership in the 1990s than with its
actual role in the road network. Ontario government downloaded the
roads it could onto the regions and cities, but of course the volume
of traffic or significance of the road doesn't change just because we
enter a somewhat-built-up area (or it increases). There's some good
examples along Highway 7 entering east Kitchener and east Guelph.
Highways 8 and 24 entering south Cambridge are more examples - it's
just a cut at point of jurisdiction change, it's got nothing to do
with the actual road or its use.

As a result, we don't really show the main roads in Ontario cities. We
mostly jump from a freeway straight to secondary, and most exceptions
are recent changes.

To an extent a grid system, which most Ontario cities use, does of
course consist of a number of fairly equal arterials, but natural
obstacles often get in the way, and so in Toronto/GTA some arterials
are more equal than others. Is every grid street really the same rank?
When everything is secondary, what really is secondary?

To give some examples, in Toronto Lake Shore Blvd is clearly a busier
road and can carry more inter-local traffic than Church or Yonge
downtown, yet currently they're all secondary. Adelaide and Richmond
are the designated through corridors - consider especially their
direct connection to the DVP. Given the choice, you should be driving
on Adelaide/Richmond, not on Queen - they are designed for this. Yet
again, Queen, Adelaide, and Richmond are currently all secondary.

Until last year, York Region's Highway 7 was being indicated the same
secondary as Dundas Street next to Dundas Square (because after all,
Hwy 7 was downloaded). They are clearly not even close to being the
same category - which would you rather walk along? which would you
rather drive 10 km along? Same with Highway 27 [3].

Provincial ownership gives us more curious examples. Check out the
official provincial Highway 7: https://osm.org/relation/4114735 (and
see dissenting view below for tagging of the non-classified parts). In
Thorold, there is a short stretch of primary connnecting five

Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Per discussione Erwin Olario
Thank you for pitching-in Eugene, and thank you everyone for your inputs.

I would like to specify that in the example mentioned by Eugene, the
dataset is not publicly distributed -- but there are extra-legal copies
going around the Internet. The government agency who created the geodata is
the Philippine Statistical Authority (which isn't, by the way,  the
government agency responsible for defining authoritative boundaries) sold
them for the purpose of helping end-users visualize the statistical data
they create. The condition of their sale (similar to the Memorandum of
Agreement with NAMRIA) was that end-users may use the data on the disc
internally, but may not re-distribute them publicly. They stopped selling
the data 10 years ago, and they never published the geodata.

IMO, the copies getting around that users may be utilizing is sullied by
the fact that it wasn't meant for distribution, so users cannot grant any
rights to OSM, which they didn't have in the first place. This wouldn't be
an issue if the data is being made available by the agency itself, which it
isn't.

At any rate, these discussions are indeed very helpful for elucidating the
position our community should take. And, we take note of Simon's advise
that a conservative interpretation might be prudent.

Looking forward to more of your inputs. Thank you.

- - - - - - - - - - - - - - - - - - -
» email: erwin@ *n**gnu**it**y**.xyz*
 | gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Fri, Jul 17, 2020 at 5:00 AM Eugene Alvin Villar 
wrote:

> Hi Kathleen, all,
>
> Just as a bit of reference, the original intellectual property law from
> 1924, back when the Philippines was a territory of the United States,
> didn't have this commercial-with-prior-approval second sentence and was
> basically modeled after the U.S. law (government works are fully in the
> public domain). This additional sentence was added in 1972 and was retained
> in the present law of 1997. Previous analysis of the current law by
> Wikimedia volunteers with respect to copyright can be seen here and which
> concludes that this second sentence is some sort of additional
> non-copyright-based government right:
> https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Template:PD-PhilippineGov
>
> This situation actually raises a lot of questions especially in the
> context of OSM. For instance, if a government agency published a dataset of
> polygons of places, it would probably be best to get the agency's prior
> approval to import such dataset in order to waive the requirement of "prior
> approval [...] for exploitation of such work for profit" because end users
> of OSM should not have to ask the agency for approval if they want to use
> the data that was included in OSM for profit.
>
> On the other hand, if an OSM mapper *derives* new data from such a
> dataset (for example, generating a representative point for each polygon,
> maybe at the centroid, or maybe at at the "admin centre" if the polygon
> represents settlements and the mapper used their best judgement and
> research to place such points), then this new dataset is no longer the same
> as the government dataset. If the OSM mapper added the new derived data to
> OSM, then one could perhaps argue that prior approval from the government
> agency is no longer needed because the very act of mapping in OSM is not
> "for exploitation of such work for profit". And furthermore, end users of
> OSM would also perhaps not need to seek "prior approval" as well since they
> are not exploiting the original government dataset but rather a derived
> dataset (ex., points), and which cannot be used to reverse engineer the
> original government dataset (ex., polygons).
>
> Regards,
> Eugene
>
>
>
> On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk <
> legal-talk@openstreetmap.org> wrote:
>
>> A few thoughts:
>>
>> I'd want to talk to a Philippine lawyer, because frankly, these two
>> sentences seem to contradict each other:
>> *No copyright shall subsist in any work of the Government of the
>> Philippines. However, prior approval of the government agency or office
>> wherein the work is created shall be necessary for exploitation of such
>> work for profit*
>>
>> What would be the consequences of not getting permission? A violation of
>> the government's non-copyright rights? Rights of what? I didn't think the
>> Philippines had database rights, but there could well be some other
>> non-copyright law.
>>
>> Looking online, I found this on the National Mapping authority's website:
>> Can I edit and use the NAMRIA maps for business? Article III of NAMRIA
>> Memorandum of Agreement (MOA) states that "the second party shall use the
>> digital data acquired from NAMRIA only for its own authorized purpose and
>> not for commercial purpose. If digital is sold to other parties, the Second
>> Party shall pay the full cost of the 

Re: [Talk-transit] bus stop name

2020-07-16 Per discussione Dave F via Talk-transit
The whole point of route relations is to allow multiple routes to be 
added to an individual object.


On 17/07/2020 02:15, 80hnhtv4agou--- via Talk-transit wrote:
    In the USA bus stops (flag stops) are located for the most part at 
named intersections, that is at where the street

sign is.
   so you DO know where you are. but on the OSM standard map the bus 
stop tag depending on the
editor does not show the route number, can you have the route number 
on the tag ?

​​​the wiki on this seems to be written for a European standard.

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


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


Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Kevin Farrugia
Yeah, it changes from place to place and what has historically been
the standard.  I'm not against changing the standard, maybe we just need a
better or updated definition for what can be a primary road in Ontario.

Perhaps we make some standards for the heavily urbanised areas of Ontario
where "provincial highway or former provincial highway" isn't a useful
definition.  There are several Regional roads/numbered city roads that
would come to mind that would be decent candidates, as they connect lower
and/or upper tier municipalities, usually direct traffic to 400-Series
Highways, have heavy volume, and allow trucks.

Thoughts?

-Kevin


On Thu, 16 Jul 2020 at 21:08, Andrew Deng  wrote:

> I thought the tagging would be similar to the US, where roads are tagged
> based on its traffic volume and importance which is why I thought Yonge
> should be Primary. I see now.
>
> --
>
>
>
> Andrew
> Student
>
>
> On Thursday, July 16, 2020, 08:31:48 p.m. EDT, Kevin Farrugia <
> kevinfarru...@gmail.com> wrote:
>
>
> Hey Andrew,
>
> I'm in agreement with Justin.  I think it's too urban a road, with urban
> speed limits along almost its entire length and many traffic lights.  I
> definitely wouldn't consider the part of Yonge through downtown Toronto (or
> most of Toronto for that matter) to be Primary, with truck traffic banned
> and urban speed limits/road designs.  Arguably the subway has lowered the
> importance of Yonge Street for cars/trucks.  As for intercity travel, the
> 400-Series Highways have generally made travel using former King's Highways
> in the Golden Horseshoe a thing of the past (hence the download in the
> '90s), so being a former Provincial Highway is too simple of a definition,
> IMO.
>
> Some of those former King's Highways you mentioned in your email were
> tagged as Secondary from when they were first digitized until they were
> changed a year or so ago by one user, so they haven't always been like that
> and weren't really changed by consensus (thanks for the email, btw).
>
> My thoughts/opinion anyways...
>
> Cheers,
>
> -Kevin
>
>
> On Thu, 16 Jul 2020 at 14:09, Justin Tracey  wrote:
>
> In Canada, highway=primary is typically used for what I would call
> "highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many
> cross streets to be really considered highway-like, at least for most of
> its length. You can look at some of the other highway=primary roads in the
> area to see a more typical cross-traffic density. That said, I certainly
> wouldn't engage in an edit war over it or anything.
>
>  - Justin
>
> [0]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below
>
> On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
>
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1)
> should be tagged as highway=primary rather than highway=secondary as it is
> tagged now.
>
> Here are some reasons I believe why:
>
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
>
> 2) It is a major thoroughfare throughout the route. In Toronto, the Yonge
> subway follows it and in York Region, Viva bus lanes are being built. It
> also connects to Bradford in the north.
>
> 3) It was a former Ontario King's Highway - Highway 11. Some other former
> King's Highways in the Toronto/York area are tagged as highway=primary,
> such as Highway 27, Highway 7, and Highway 48.
>
> --
>
>
>
> Andrew
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-transit] bus stop name

2020-07-16 Per discussione 80hnhtv4agou--- via Talk-transit

    In the USA bus stops (flag stops) are located for the most part at named 
intersections, that is at where the street 
 
sign is.
 
   so you DO know where you are. but on the OSM standard map the bus stop tag 
depending on the
 
editor does not show the route number, can you have the route number on the tag 
?
 
​​​the wiki on this seems to be written for a European standard.
 
 
 ___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Andrew Deng via Talk-ca
I thought the tagging would be similar to the US, where roads are tagged based 
on its traffic volume and importance which is why I thought Yonge should be 
Primary. I see now.
--
 

Andrew
Student 

On Thursday, July 16, 2020, 08:31:48 p.m. EDT, Kevin Farrugia 
 wrote:  
 
 Hey Andrew,
I'm in agreement with Justin.  I think it's too urban a road, with urban speed 
limits along almost its entire length and many traffic lights.  I definitely 
wouldn't consider the part of Yonge through downtown Toronto (or most of 
Toronto for that matter) to be Primary, with truck traffic banned and urban 
speed limits/road designs.  Arguably the subway has lowered the importance of 
Yonge Street for cars/trucks.  As for intercity travel, the 400-Series Highways 
have generally made travel using former King's Highways in the Golden Horseshoe 
a thing of the past (hence the download in the '90s), so being a former 
Provincial Highway is too simple of a definition, IMO.
Some of those former King's Highways you mentioned in your email were tagged as 
Secondary from when they were first digitized until they were changed a year or 
so ago by one user, so they haven't always been like that and weren't really 
changed by consensus (thanks for the email, btw).
My thoughts/opinion anyways...
Cheers,

-Kevin


On Thu, 16 Jul 2020 at 14:09, Justin Tracey  wrote:

  In Canada, highway=primary is typically used for what I would call 
"highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many cross 
streets to be really considered highway-like, at least for most of its length. 
You can look at some of the other highway=primary roads in the area to see a 
more typical cross-traffic density. That said, I certainly wouldn't engage in 
an edit war over it or anything.
 
  - Justin
 
 
[0]https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below
 
 On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
  
  Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1) 
should be tagged as highway=primary rather than highway=secondary as it is 
tagged now. 
  Here are some reasons I believe why: 
  1) Yonge Street is considered the "Main Street" of Toronto, Thornhill, 
Richmond Hill, and Aurora. It is also a major road in Newmarket. 
  2) It is a major thoroughfare throughout the route. In Toronto, the Yonge 
subway follows it and in York Region, Viva bus lanes are being built. It also 
connects to Bradford in the north. 
  3) It was a former Ontario King's Highway - Highway 11. Some other former 
King's Highways in the Toronto/York area are tagged as highway=primary, such as 
Highway 27, Highway 7, and Highway 48.  
--  
 
 
Andrew
 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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


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

2020-07-16 Per discussione 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


[OSM-talk] private or not, USA ?

2020-07-16 Per discussione 80hnhtv4agou--- via talk

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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[Talk-us] private or not, USA ?

2020-07-16 Per discussione 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-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Kevin Farrugia
Hey Andrew,

I'm in agreement with Justin.  I think it's too urban a road, with urban
speed limits along almost its entire length and many traffic lights.  I
definitely wouldn't consider the part of Yonge through downtown Toronto (or
most of Toronto for that matter) to be Primary, with truck traffic banned
and urban speed limits/road designs.  Arguably the subway has lowered the
importance of Yonge Street for cars/trucks.  As for intercity travel, the
400-Series Highways have generally made travel using former King's Highways
in the Golden Horseshoe a thing of the past (hence the download in the
'90s), so being a former Provincial Highway is too simple of a definition,
IMO.

Some of those former King's Highways you mentioned in your email were
tagged as Secondary from when they were first digitized until they were
changed a year or so ago by one user, so they haven't always been like that
and weren't really changed by consensus (thanks for the email, btw).

My thoughts/opinion anyways...

Cheers,

-Kevin


On Thu, 16 Jul 2020 at 14:09, Justin Tracey  wrote:

> In Canada, highway=primary is typically used for what I would call
> "highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many
> cross streets to be really considered highway-like, at least for most of
> its length. You can look at some of the other highway=primary roads in the
> area to see a more typical cross-traffic density. That said, I certainly
> wouldn't engage in an edit war over it or anything.
>
>  - Justin
>
> [0]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below
>
> On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
>
> Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1)
> should be tagged as highway=primary rather than highway=secondary as it is
> tagged now.
>
> Here are some reasons I believe why:
>
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
>
> 2) It is a major thoroughfare throughout the route. In Toronto, the Yonge
> subway follows it and in York Region, Viva bus lanes are being built. It
> also connects to Bradford in the north.
>
> 3) It was a former Ontario King's Highway - Highway 11. Some other former
> King's Highways in the Toronto/York area are tagged as highway=primary,
> such as Highway 27, Highway 7, and Highway 48.
>
> --
>
>
>
> Andrew
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Per discussione Simon Poole
This is not a particular unique situation, a sovereign country can,
naturally, create exclusive rights or specific regulation for more or
less whatever it cares.

Copyright is simply the most popular, with wide spread understanding and
international treaties as support, set of exclusive intellectual
property rights. But there is nothing stopping a government special
casing geodata or other ip that they produce, or introducing special
protection for otherwise not protected works, there can simply be no
expectation that such regulation could be internationally enforced and
reciprocal. Two examples are the national geo information law where I
live and sui generis database rights in the EU.

(Omiting some edge cases here, essentially the ones that you shouldn't
ask about, because you wont like the answer) OSM is interested in its
geodata being useful and usable globally, and because of its nature,
particulary in the country the data is relevant in. As a result, unlike
other projects, we can't ignore national quirks and restrictions and
need to accomodate them as far as it is compatible with our mission.

So in this case I would take the conservative stance (as our licence is
open and does not discriminate against commercial use) and suggest that
any use of government data would need permisson. I would not try to
outlawyer the government as your argumentation would seem to imply you
would like to do.

Naturally it is completly possible to produce a fully functional map
without resorting to government data, so not getting such permission is
not a show stopper.

tl;dr version: if you have quirky national regulations then please abide
by them so that your work contributing to OSM is not in vain. If you are
a resident in one of the edge case territories, you should read the OSMF
ToU and carefully consider your situation.

Simon

On 16.07.2020 22:59, Eugene Alvin Villar wrote:
> Hi Kathleen, all,
>
> Just as a bit of reference, the original intellectual property law
> from 1924, back when the Philippines was a territory of the United
> States, didn't have this commercial-with-prior-approval second
> sentence and was basically modeled after the U.S. law (government
> works are fully in the public domain). This additional sentence was
> added in 1972 and was retained in the present law of 1997. Previous
> analysis of the current law by Wikimedia volunteers with respect to
> copyright can be seen here and which concludes that this second
> sentence is some sort of additional non-copyright-based government
> right:
> https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Template:PD-PhilippineGov
>
> This situation actually raises a lot of questions especially in the
> context of OSM. For instance, if a government agency published a
> dataset of polygons of places, it would probably be best to get the
> agency's prior approval to import such dataset in order to waive the
> requirement of "prior approval [...] for exploitation of such work for
> profit" because end users of OSM should not have to ask the agency for
> approval if they want to use the data that was included in OSM for profit.
>
> On the other hand, if an OSM mapper /derives/ new data from such a
> dataset (for example, generating a representative point for each
> polygon, maybe at the centroid, or maybe at at the "admin centre" if
> the polygon represents settlements and the mapper used their best
> judgement and research to place such points), then this new dataset is
> no longer the same as the government dataset. If the OSM mapper added
> the new derived data to OSM, then one could perhaps argue that prior
> approval from the government agency is no longer needed because the
> very act of mapping in OSM is not "for exploitation of such work for
> profit". And furthermore, end users of OSM would also perhaps not need
> to seek "prior approval" as well since they are not exploiting the
> original government dataset but rather a derived dataset (ex.,
> points), and which cannot be used to reverse engineer the original
> government dataset (ex., polygons).
>
> Regards,
> Eugene
>
>
>
> On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk
> mailto:legal-talk@openstreetmap.org>>
> wrote:
>
> A few thoughts:
>
> I'd want to talk to a Philippine lawyer, because frankly, these
> two sentences seem to contradict each other: /_No copyright shall
> subsist in any work of the Government of the Philippines. However,
> prior approval of the government agency or office wherein the work
> is created shall be necessary for exploitation of such work for
> profit_
> /
>
> What would be the consequences of not getting permission? A
> violation of the government's non-copyright rights? Rights of
> what? I didn't think the Philippines had database rights, but
> there could well be some other non-copyright law.
>
> Looking online, I found this on the National Mapping authority's
> website:
> Can I edit 

Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Per discussione Kathleen Lu via legal-talk
Thanks for the context Eugene.

On the other hand, if an OSM mapper *derives* new data from such a dataset
> (for example, generating a representative point for each polygon, maybe at
> the centroid, or maybe at at the "admin centre" if the polygon represents
> settlements and the mapper used their best judgement and research to place
> such points), then this new dataset is no longer the same as the government
> dataset. If the OSM mapper added the new derived data to OSM, then one
> could perhaps argue that prior approval from the government agency is no
> longer needed because the very act of mapping in OSM is not "for
> exploitation of such work for profit". And furthermore, end users of OSM
> would also perhaps not need to seek "prior approval" as well since they are
> not exploiting the original government dataset but rather a derived dataset
> (ex., points), and which cannot be used to reverse engineer the original
> government dataset (ex., polygons).
>
> This interpretation would seem to be consistent with the answer provided
on the National Mapping authority's website:
Can I edit and use the NAMRIA maps for business? Article III of NAMRIA
Memorandum of Agreement (MOA) states that "the second party shall use the
digital data acquired from NAMRIA only for its own authorized purpose and
not for commercial purpose. If digital is sold to other parties, the Second
Party shall pay the full cost of the digital data and its royalties". This
applies only to digital maps (scanned/vector) purchased from NAMRIA.

If it is not the data itself but rather derived from it, then there are no
restrictions.

-Kathleen



> On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk <
> legal-talk@openstreetmap.org> wrote:
>
>> A few thoughts:
>>
>> I'd want to talk to a Philippine lawyer, because frankly, these two
>> sentences seem to contradict each other:
>> *No copyright shall subsist in any work of the Government of the
>> Philippines. However, prior approval of the government agency or office
>> wherein the work is created shall be necessary for exploitation of such
>> work for profit*
>>
>> What would be the consequences of not getting permission? A violation of
>> the government's non-copyright rights? Rights of what? I didn't think the
>> Philippines had database rights, but there could well be some other
>> non-copyright law.
>>
>> Looking online, I found this on the National Mapping authority's website:
>> Can I edit and use the NAMRIA maps for business? Article III of NAMRIA
>> Memorandum of Agreement (MOA) states that "the second party shall use the
>> digital data acquired from NAMRIA only for its own authorized purpose and
>> not for commercial purpose. If digital is sold to other parties, the Second
>> Party shall pay the full cost of the digital data and its royalties". This
>> applies only to digital maps (scanned/vector) purchased from NAMRIA.
>> http://www.namria.gov.ph/faq.aspx
>>
>> So one question I would have is whether the data source in question is
>> digital data acquired from NAMRIA?
>>
>> I also found this list
>> http://www.geoportal.gov.ph/resources/PGPDataInventorywithSW
>> which seems to indicate that at least some government geodata has no
>> restrictions on it. With respect to at least those datasets, it would seem
>> that *explicit permission with respect to OSM* is unnecessary. I didn't see
>> a source for the letters mentioned in this list, but it's possible that
>> some of the data restrictions would not be a problem for OSM, but they'd
>> have to be examined on a letter by letter basis.
>>
>> Best,
>> -Kathleen
>>
>>
>> On Wed, Jul 15, 2020 at 6:17 PM Erwin Olario  wrote:
>>
>>> Recently, some edits in the country came to the  attention of the
>>> community and have been found to be derived from government data.
>>> Volunteers in the community, after advising the DWG of the process and
>>> action plan, are undertaking the rollback of affected edits.
>>>
>>> In our community, the current practice follows the general
>>> recommendation, that  no (Philippine government) data should be added into
>>> OpenStreetMap, unless explicit permission has been obtained from the
>>> originating agency/office/owners that the data will be added in OSM, under
>>> ODbL.
>>>
>>> The relevant local law on government data, states Republic Act 8293
>>> ,
>>> section 176:
>>> "*Works of the Government. ‑ 176.1. No copyright shall subsist in any
>>> work of the Government of the Philippines. However, prior approval of the
>>> government agency or office wherein the work is created shall be necessary
>>> for exploitation of such work for profit. Such agency or office may, among
>>> other things, impose as a condition the payment of royalties. No prior
>>> approval or conditions shall be required for the use for any purpose of
>>> statutes, rules and regulations, and speeches, lectures, sermons,
>>> addresses, and dissertations, 

Re: [Talk-at] Autobahn Baukilometer

2020-07-16 Per discussione Andreas
Hallo Philipp,

ich habe nochmal drüber nachgedacht und glaube du müsstest mit den
Bezugspunkten von der GIP auskommen. Die Bezugspunkte liegen ja als
Punkt-Feature vor und daher hat jeder Bezugspunkt entsprechende
Koordinaten. Mit einem GIS Programm deiner Wahl, zb QGIS kannst du dir
die Koordinaten zusätzlich als Attribute ausgeben lassen und zu den
Bezugspunkten dazu speichern.

lg Andreas
(geologist)

Am 16.07.20 um 22:55 schrieb Andreas:
> Am 16.07.20 um 08:29 schrieb Philipp Kolmann:
>> Hallo Liste,
> 
> Hallo Philipp,
> 
>>
>> weiss jemand, ob es eine Liste der Koordinaten für die Autobahn
>> Baukilometer gibt. Ich arbeite an einem Programm für meine Feuerwehr, wo
>> bei Alarmen ein PDF ausgedruckt wird, mit der Adresse.
>>
> 
> Eine österreichweite Liste ist mir nicht bekannt. Auf
> https://www.data.gv.at/ findest du teilweise für bestimmte Bundesländer
> eine detailliertere Aufstellung. Aus der Dokumentation des GIP
> Datensatzes http://open.gip.gv.at/ogd/0_dokumentation_gipat_ogd.pdf
> findest du dann die genauer Beschreibung der einzelnen Datenobjekte.
> 
> Brauchst du wirklich für das ganze Autobahnnetz die Daten oder nicht nur
> für das Einsatzgebiet deiner Feuerwehr?
> 
>> Für Autobahnen habe ich aber kein Mapping der Baukilometer auf
>> Positionen. Ich hab mir schon den Datensatz von gip.gv.at angeschaut,
>> aber da hab ich auch keine Baukilometer gefunden.
> 
> Da sind die Kilometerzeichen als "Bezugspunkte" erfasst. Wie du in der
> GIP Standard Beschreibung finden kannst, werden unterschiedliche
> Kilometrierungssysteme in Österreich verwendet.
> 
> In der GIP sind die Bezugspunkte aufgrund der Position auf dem Abschnitt
> (EDGEPROZ) verspeichert. Aufgrund dieser Postion müssten sich die
> Koordinaten ableiten lassen.
> 
>>
>> Danke für Hinweise,
> 
> Sorry, dass ich dir nicht mehr weiterhelfen kann.
> 
>> lg
>> Philipp
>>
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




signature.asc
Description: OpenPGP digital signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Andy Robinson
You can see from my attempt 11 years ago that I didn't have a clue either!

https://www.openstreetmap.org/node/484792823

http://www.mappa-mercia.org/2009/11/pelsall-pleasure.html

Cheers
Andy

-Original Message-
From: Andy Mabbett [mailto:a...@pigsonthewing.org.uk] 
Sent: 16 July 2020 17:00
To: talk-gb-westmidlands
Subject: [Talk-gb-westmidlands] Fingerposts

I've just come to map a fingerpost, never having had cause to add one
previously.

To my surprise there is nothing on the wiki about how to do so, and I
can find no JSOM preset.

What do folk suggest?

I would like to add the inscription, for each of the three fingers,
with their comaps points, something like:

   inscription:NW=foo

or, using degrees:

   inscription:315:=foo

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


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


[OSM-talk-fr] Découpage administratif à Paris, les conseils de quartier

2020-07-16 Per discussione Brice

Le découpage administratif, tel que défini pour la France
https://wiki.openstreetmap.org/wiki/FR:Tag:boundary%3Dadministrative#Valeurs_sp.C3.A9cifiques_par_pays_pour_admin_level
défini admin_level=10 comme "limites des quartiers utilisés pour la 
démocratie locale"


Dans le cas de Paris,
sous l'arrondissement (admin_level=9)
ont été tracés 80 quartiers administratifs 
(https://fr.wikipedia.org/wiki/Liste_des_quartiers_administratifs_de_Paris) 
avec admin_level=10

exemple : https://www.openstreetmap.org/relation/2195038

Mais il se trouve qu'il y a un découpage encore plus fin : les conseils 
de quartier 
(https://fr.wikipedia.org/wiki/Conseils_de_quartier_de_Paris) définis 
avec une extension territoriale 
(https://www.apur.org/sites/default/files/documents/54.pdf), il y en a 
124 dans Paris.

Cas particuliers :
- dans le  1er, 3ème, 4ème, 5ème et 7ème arrondissements les conseils de 
quartier ont la même extension que les quartiers administratifs (soit 4 
/ arrondissement)
- dans le  2ème, un conseil de quartier s'étend sur 2 quartiers 
adminsitratifs


Si on se réfère à "limites des quartiers..." alors admin_level=10 
correspond bien au quartier administratif
mais si on se réfère à la deuxième partie de la définition ("...utilisés 
pour la démocratie locale") alors admin_level=10 correspond au conseil 
de quartier, à Paris.


Je prévois de tracer ces conseils de quartier, que faire ?
1/ leur attribuer un admin_level=11 ? : ne fonctionnera pas dans le 
2ème, ni 1er à 7 non plus d'ailleurs (ou si ?)
2/ déclasser les quartiers actuels (mais pour en faire quoi) et 
attribuer admin_level=10 aux conseils de quartier ?
3/ un autre type de balisage, à la façon des EPCI 
(https://wiki.openstreetmap.org/wiki/France/Limites_administratives/Tracer_les_limites_administratives#.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale_.28EPCI.29_.C3.A0_fiscalit.C3.A9_propre) 
?

4/ autre ?

--
Cordialement
Britzz

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


Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Per discussione Eugene Alvin Villar
Hi Kathleen, all,

Just as a bit of reference, the original intellectual property law from
1924, back when the Philippines was a territory of the United States,
didn't have this commercial-with-prior-approval second sentence and was
basically modeled after the U.S. law (government works are fully in the
public domain). This additional sentence was added in 1972 and was retained
in the present law of 1997. Previous analysis of the current law by
Wikimedia volunteers with respect to copyright can be seen here and which
concludes that this second sentence is some sort of additional
non-copyright-based government right:
https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Template:PD-PhilippineGov

This situation actually raises a lot of questions especially in the context
of OSM. For instance, if a government agency published a dataset of
polygons of places, it would probably be best to get the agency's prior
approval to import such dataset in order to waive the requirement of "prior
approval [...] for exploitation of such work for profit" because end users
of OSM should not have to ask the agency for approval if they want to use
the data that was included in OSM for profit.

On the other hand, if an OSM mapper *derives* new data from such a dataset
(for example, generating a representative point for each polygon, maybe at
the centroid, or maybe at at the "admin centre" if the polygon represents
settlements and the mapper used their best judgement and research to place
such points), then this new dataset is no longer the same as the government
dataset. If the OSM mapper added the new derived data to OSM, then one
could perhaps argue that prior approval from the government agency is no
longer needed because the very act of mapping in OSM is not "for
exploitation of such work for profit". And furthermore, end users of OSM
would also perhaps not need to seek "prior approval" as well since they are
not exploiting the original government dataset but rather a derived dataset
(ex., points), and which cannot be used to reverse engineer the original
government dataset (ex., polygons).

Regards,
Eugene



On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk <
legal-talk@openstreetmap.org> wrote:

> A few thoughts:
>
> I'd want to talk to a Philippine lawyer, because frankly, these two
> sentences seem to contradict each other:
> *No copyright shall subsist in any work of the Government of the
> Philippines. However, prior approval of the government agency or office
> wherein the work is created shall be necessary for exploitation of such
> work for profit*
>
> What would be the consequences of not getting permission? A violation of
> the government's non-copyright rights? Rights of what? I didn't think the
> Philippines had database rights, but there could well be some other
> non-copyright law.
>
> Looking online, I found this on the National Mapping authority's website:
> Can I edit and use the NAMRIA maps for business? Article III of NAMRIA
> Memorandum of Agreement (MOA) states that "the second party shall use the
> digital data acquired from NAMRIA only for its own authorized purpose and
> not for commercial purpose. If digital is sold to other parties, the Second
> Party shall pay the full cost of the digital data and its royalties". This
> applies only to digital maps (scanned/vector) purchased from NAMRIA.
> http://www.namria.gov.ph/faq.aspx
>
> So one question I would have is whether the data source in question is
> digital data acquired from NAMRIA?
>
> I also found this list
> http://www.geoportal.gov.ph/resources/PGPDataInventorywithSW
> which seems to indicate that at least some government geodata has no
> restrictions on it. With respect to at least those datasets, it would seem
> that *explicit permission with respect to OSM* is unnecessary. I didn't see
> a source for the letters mentioned in this list, but it's possible that
> some of the data restrictions would not be a problem for OSM, but they'd
> have to be examined on a letter by letter basis.
>
> Best,
> -Kathleen
>
>
> On Wed, Jul 15, 2020 at 6:17 PM Erwin Olario  wrote:
>
>> Recently, some edits in the country came to the  attention of the
>> community and have been found to be derived from government data.
>> Volunteers in the community, after advising the DWG of the process and
>> action plan, are undertaking the rollback of affected edits.
>>
>> In our community, the current practice follows the general
>> recommendation, that  no (Philippine government) data should be added into
>> OpenStreetMap, unless explicit permission has been obtained from the
>> originating agency/office/owners that the data will be added in OSM, under
>> ODbL.
>>
>> The relevant local law on government data, states Republic Act 8293
>> ,
>> section 176:
>> "*Works of the Government. ‑ 176.1. No copyright shall subsist in any
>> work of the Government of the Philippines. However, 

Re: [Talk-at] Autobahn Baukilometer

2020-07-16 Per discussione Andreas
Am 16.07.20 um 08:29 schrieb Philipp Kolmann:
> Hallo Liste,

Hallo Philipp,

> 
> weiss jemand, ob es eine Liste der Koordinaten für die Autobahn
> Baukilometer gibt. Ich arbeite an einem Programm für meine Feuerwehr, wo
> bei Alarmen ein PDF ausgedruckt wird, mit der Adresse.
>

Eine österreichweite Liste ist mir nicht bekannt. Auf
https://www.data.gv.at/ findest du teilweise für bestimmte Bundesländer
eine detailliertere Aufstellung. Aus der Dokumentation des GIP
Datensatzes http://open.gip.gv.at/ogd/0_dokumentation_gipat_ogd.pdf
findest du dann die genauer Beschreibung der einzelnen Datenobjekte.

Brauchst du wirklich für das ganze Autobahnnetz die Daten oder nicht nur
für das Einsatzgebiet deiner Feuerwehr?

> Für Autobahnen habe ich aber kein Mapping der Baukilometer auf
> Positionen. Ich hab mir schon den Datensatz von gip.gv.at angeschaut,
> aber da hab ich auch keine Baukilometer gefunden.

Da sind die Kilometerzeichen als "Bezugspunkte" erfasst. Wie du in der
GIP Standard Beschreibung finden kannst, werden unterschiedliche
Kilometrierungssysteme in Österreich verwendet.

In der GIP sind die Bezugspunkte aufgrund der Position auf dem Abschnitt
(EDGEPROZ) verspeichert. Aufgrund dieser Postion müssten sich die
Koordinaten ableiten lassen.

> 
> Danke für Hinweise,

Sorry, dass ich dir nicht mehr weiterhelfen kann.

> lg
> Philipp
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at




signature.asc
Description: OpenPGP digital signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


[Talk-GB] POI files of Pub/Restaurant chain

2020-07-16 Per discussione Rob Nickerson
Harvester is one of many brands owned by M: https://www.mbplc.com/

Try writing to the parent group as you might get permission for all of
their brands.

Best regards
Rob

P.s. sorry for lack of threaded email. I'm still struggling with nabble.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-ro] Actualizare admin_level pe wiki

2020-07-16 Per discussione Attila Asztalos
Eu personal apreciez ca vad o discutie pe care absolut n-as vedea-o in 
alte circumstante.



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


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

2020-07-16 Per discussione 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-ro] Actualizare admin_level pe wiki

2020-07-16 Per discussione Razvan
Salut. Cred ca toată discuția asta trebuia purtata și pe pagina Facebook a
osm România. Sunt mult mai mulți  care ar vedea  ce se discuta...

joi, 16 iul. 2020, 20:18 Vlad Sîngeorzan  a scris:

> În urma unor discuții cu ted3sco am ajuns la o altă schemă de tagging,
> luând ca exemplu țările vecine și cele mai bine completate. În propunerea
> mea inițială, UAT-urile erau la un nivel mai înalt decât nivelul folosit în
> alte țări la diviziune cu mărimi asemănătoare, astfel propunerea actuală
> este în felul următor:
>
>- 3: N/A
>- 4: Macroregiuni (NUTS1) sau împărțiri de mărime echivalentă dacă vor
>fi folosite în administrație
>- 5: Regiuni (NUTS2) idem
>- 6: Județe (NUTS3) lăsate momentan la nivel 4
>- 7: Zone metropolitane sau alte tipuri de asociații între UATuri;
>sectoarele Bucureștiului
>- 8: Comune, orașe, municipii
>- 9: Localitățile componente ale comunelor/orașelor/municipiilor
>- 10: Cartiere
>
>
> În lun., 29 iun. 2020 la 14:32, Vlad Sîngeorzan  a
> scris:
>
>> Nu sunt sigur dacă s-au transmis imaginile prin lista de Mail așa că
>> atașez de asemenea și un document Excel și un link de Google Sheets
>>
>> https://docs.google.com/spreadsheets/d/1H-XGjrIioRF8ijtkc9AHogZWE9Ot92aN8I_SbkZwxhw/edit?usp=sharing
>>
>> ___
> Talk-ro mailing list
> Talk-ro@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ro
>
___
Talk-ro mailing list
Talk-ro@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ro


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

2020-07-16 Per discussione 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


Re: [Talk-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Andy Townsend

On 16/07/2020 17:20, Alan Mackie wrote:

Maybe:
tourism=information
information=guidepost
?

https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost

I don't know a way of recording the directions they point save via 
destination_sign relations.


https://wiki.openstreetmap.org/wiki/Relation:destination_sign

On Thu, 16 Jul 2020, 17:00 Andy Mabbett, > wrote:


I've just come to map a fingerpost, never having had cause to add one
previously.

I had a look at this a while back because I was figuring out how to best 
render stuff in the "information" space. "tourism=information; 
information=guidepost" does seem to what people use for those, at least 
in the UK.


The tricky bit is that in England and Wales at least what might be 
described as a "fingerpost" might cover a whole range of things - it 
might be (1) a bit of wood with "public footpath" written on it, or (2) 
it might say "to St Gregory's Minster" or somesuch.  It might be (3) a 
route marker for a long or short distance path, or it might be a 
combination of some or all of these.  Even "simple public footpath 
markers" vary hugely around the place (even just around what might be 
called the West Mids) in terms of what form they take, how frequent they 
are and what other information they carry.


https://wiki.openstreetmap.org/wiki/Proposed_features/Guidepost and 
https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost describe 
what I might call "European" guideposts, which Andy's example might be 
similar to from the description, but it's not much use with what I 
suspect Phil was thinking about when he said "we tend to just use them 
to confirm the legal status of a right of way".


The tag combinations in use seem to be a bit of a mish-mash (see 
https://taginfo.openstreetmap.org/tags/information=guidepost#combinations 
; unfortunately it looks like there aren't enough to get stats at 
https://taginfo.openstreetmap.org.UK/tags/information=guidepost#combinations 
).  Where someone local to me added lots of "basic public footpath 
signs" as "tourism=information; information=guidepost"I added a 
"guidepost_type" tag to the ones that I knew weren't "just" public 
footpath markers (see 
https://taginfo.openstreetmap.org/keys/guidepost_type#values ).  I 
picked "guidepost_type"because I couldn't see another option available 
and in use in England and Wales that could make that distinction - I'd 
be happy to change that tag to something else if someone comes up with a 
better option.


The idea is to make sure that there's enough information stored for a 
renderer to be able to do different things based on whether an 
"information=guidepost" (or an "information=route_marker") is one of 
(1), (2) or (3) above or a combination, and to do different things with 
it on that basis.


As an aside, I've been adding examples of (3) to the relevant relation 
(see e.g. https://www.openstreetmap.org/relation/1996318 ) so that, come 
the glorious day when I manage to set up a version of osm2pgsql that 
supports doing something useful with that information you'll be able to 
see not just that there's a guidepost here but that it's actually a 
marker for XYZ long distance trail.  See 
https://pavie.info/2020/03/09/openstreetmap-data-processing-osm2pgsql-flex/ 
for a bit of info about that.


Best Regards,

Andy


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


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

2020-07-16 Per discussione 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-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Andy Mabbett
On Thu, 16 Jul 2020 at 17:20, Alan Mackie  wrote:

> On Thu, 16 Jul 2020, 17:00 Andy Mabbett,  wrote:

>> I've just come to map a fingerpost, never having had cause to add one
>> previously.

> Maybe:
> tourism=information
> information=guidepost

> https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost

Thank you. That seems to be it, though the page doesn't include the
strings "fingerposts" or "finger posts". I've added it, and made some
redirects.

> I don't know a way of recording the directions they point save via 
> destination_sign relations

I'll ask on the tagging list. Wish me luck ;-)

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Justin Tracey
In Canada, highway=primary is typically used for what I would call
"highway-like" roads.[0] IMHO, Yonge is a "major" road, but has too many
cross streets to be really considered highway-like, at least for most of
its length. You can look at some of the other highway=primary roads in
the area to see a more typical cross-traffic density. That said, I
certainly wouldn't engage in an edit war over it or anything.

 - Justin

[0]
https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Sub-national_and_below

On 2020-07-16 11:28 a.m., Andrew Deng via Talk-ca wrote:
> Hello, I believe Yonge Street in Toronto and York Region (Regional
> Road 1) should be tagged as highway=primary rather than
> highway=secondary as it is tagged now.
>
> Here are some reasons I believe why:
>
> 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
>
> 2) It is a major thoroughfare throughout the route. In Toronto, the
> Yonge subway follows it and in York Region, Viva bus lanes are being
> built. It also connects to Bradford in the north.
>
> 3) It was a former Ontario King's Highway - Highway 11. Some other
> former King's Highways in the Toronto/York area are tagged as
> highway=primary, such as Highway 27, Highway 7, and Highway 48. 
>
> --
>
>  
>
> Andrew
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

2020-07-16 Per discussione 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?

2020-07-16 Per discussione 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-it] Sondaggio OpenStreetMap Italia

2020-07-16 Per discussione Anisa Kuci

Ciao a tutti,

in questo link 
 
trovate le slide con le statistiche del sondaggio rivolto alla comunità 
di OSM Italia.


Chiedo scusa per il ritardo e spero davvero che troverete i risultati 
interessanti quanto li ho trovati io.


Penso che siano un buon punto di partenza per riflettere su molte cose 
riguardanti la situazione attuale di OSM Italia e vedere dove possiamo 
lavorare di più.


Nell'ultimo slide trovate un link di un pad creato per commenti o altre 
idee che volete condividere. :)


Vi ringrazio tantissimo per tutte le vostre risposte, per le idee e 
proposte e per il tempo dedicato al sondaggio!


Buona serata e buona mappatura,

Anisa


On 7/12/20 2:15 PM, Anisa Kuci wrote:


Ciao a tutti,

vorrei proporre un incontro aperto a tutta la comunità OSM italiana 
dove condividerò con voi una presentazione dei risultati del sondaggio 
che vi ho inviato qualche settimana fa.


Le risposte sono state molte e le statistiche sono molto interessanti. 
Vi prego di partecipare all'incontro in modo da poterne discutere insieme.


Propongo il *15 luglio (mercoledì) alle 17:00*. Ci troviamo in questa 
 stanza Jitsi.


La presentazione con i risultati sarà pubblicata nella lista talk-it - 
ovviamente senza i dati personali di nessuno - dopo l'incontro, così 
chiunque voglia può tornare a vederli in dettaglio.


Grazie a tutti e buona domenica!

A presto,

Anisa



On 6/19/20 7:20 PM, Anisa Kuci wrote:


Ciao,

C'è tempo fino a lunedì (22 giugno) per compilare il sondaggio 
(APERTO A TUTTI I MEMBRI DELLA COMUNITÀ OSM ITALIA) con le vostre 
opinioni!


Condivido di nuovo il link: 
https://sondaggio.wikimedia.it/index.php/724728?lang=it


Buon weekend,

Anisa

On 6/16/20 12:32 PM, Anisa Kuci wrote:


Ciao a tutti,

questo è solo un gentile promemoria per chi non ha compilato il 
questionario che rimane attivo fino 22 Giugno.


Più risposte avremo, meglio sapremo quali sono gli argomenti più 
importanti per la comunità.


Vi ringrazio in anticipo!

Buona giornata,

Anisa

On 6/8/20 4:46 PM, Anisa Kuci wrote:


Ciao a tutti,

in collaborazione con i coordinatori di OSM Italia abbiamo 
preparato un'indagine con argomenti e attività diverse.


Chiedo gentilmente a tutta la comunità di OSM Italia di compilare 
il sondaggio 
 in modo 
da poter creare un'idea degli argomenti più importanti su cui lavorare.


Se volete condividerlo nei gruppi regionali, per favore segnalatemi 
dove è stato fatto.


Il sondaggio sarà disponibile per due settimane a partire da oggi 
(fino al 22 giugno).


Fatemi sapere se avete domande!

Buona mappatura,

Anisa


--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it  |www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it  |www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it  |www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it  |www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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


--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it

DAI ALLA CONOSCENZA 

Re: [Talk-ro] Actualizare admin_level pe wiki

2020-07-16 Per discussione Vlad Sîngeorzan
În urma unor discuții cu ted3sco am ajuns la o altă schemă de tagging,
luând ca exemplu țările vecine și cele mai bine completate. În propunerea
mea inițială, UAT-urile erau la un nivel mai înalt decât nivelul folosit în
alte țări la diviziune cu mărimi asemănătoare, astfel propunerea actuală
este în felul următor:

   - 3: N/A
   - 4: Macroregiuni (NUTS1) sau împărțiri de mărime echivalentă dacă vor
   fi folosite în administrație
   - 5: Regiuni (NUTS2) idem
   - 6: Județe (NUTS3) lăsate momentan la nivel 4
   - 7: Zone metropolitane sau alte tipuri de asociații între UATuri;
   sectoarele Bucureștiului
   - 8: Comune, orașe, municipii
   - 9: Localitățile componente ale comunelor/orașelor/municipiilor
   - 10: Cartiere


În lun., 29 iun. 2020 la 14:32, Vlad Sîngeorzan  a
scris:

> Nu sunt sigur dacă s-au transmis imaginile prin lista de Mail așa că
> atașez de asemenea și un document Excel și un link de Google Sheets
>
> https://docs.google.com/spreadsheets/d/1H-XGjrIioRF8ijtkc9AHogZWE9Ot92aN8I_SbkZwxhw/edit?usp=sharing
>
>
___
Talk-ro mailing list
Talk-ro@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ro


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

2020-07-16 Per discussione 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-it] Cancelliamo gli opening_hours:covid19 ?

2020-07-16 Per discussione liste DOT girarsi AT posteo DOT eu
Il 16/07/20 01:01, Alessandro Sarretta ha scritto:
> Secondo me non cè particolare fretta di toglierli... anche se
> attualmente, almeno in Italia, hanno perso la loro utilità. Sia per
> questo tag sia per gli altri collegati al COVID19 (e.g.
> delivery:covid19) bisognerà cmq pensare a cosa fare. Visto il tipo di
> emergenza globale (ancora pienamente in atto), credo che sarebbe il caso
> di provare a stimolare una discussione in lista internazionale... ma
> come dicevamo, prob è presto.Ale

Considerato dagli esperti, in settembre ci sarà il ritorno
dell'infezione e non si sa bene in quale misura, oltretutto non si sa
bene con quali comportamenti anche dal punto di vista degli orari
pregressi in tempo del blocco covid, propongo di aspettare la fine
dell'anno o il rossimo anno per togliere i tag e lasciarli nel limmbo
dello storico.



-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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


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

2020-07-16 Per discussione 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

2020-07-16 Per discussione 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-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Philip Barnes
I must admit that I have never thought of mapping one, we tend to just
use them to confirm the legal status of a right of way in much the same
as we map speedlimits, not the signs.

Probably map them as man_made:signpost or something similar.

They are a very common everyday object so would not fall into the
tourism category.

Phil (trigpoint)

On Thu, 2020-07-16 at 16:59 +0100, Andy Mabbett wrote:
> I've just come to map a fingerpost, never having had cause to add one
> previously.
> 
> To my surprise there is nothing on the wiki about how to do so, and I
> can find no JSOM preset.
> 
> What do folk suggest?
> 
> I would like to add the inscription, for each of the three fingers,
> with their comaps points, something like:
> 
>inscription:NW=foo
> 
> or, using degrees:
> 
>inscription:315:=foo
> 


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


Re: [Talk-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Alan Mackie
Maybe:
tourism=information
information=guidepost
?

https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost

I don't know a way of recording the directions they point save via
destination_sign relations.

https://wiki.openstreetmap.org/wiki/Relation:destination_sign

On Thu, 16 Jul 2020, 17:00 Andy Mabbett,  wrote:

> I've just come to map a fingerpost, never having had cause to add one
> previously.
>
> To my surprise there is nothing on the wiki about how to do so, and I
> can find no JSOM preset.
>
> What do folk suggest?
>
> I would like to add the inscription, for each of the three fingers,
> with their comaps points, something like:
>
>inscription:NW=foo
>
> or, using degrees:
>
>inscription:315:=foo
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands


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

2020-07-16 Per discussione 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

2020-07-16 Per discussione 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


[Talk-gb-westmidlands] Fingerposts

2020-07-16 Per discussione Andy Mabbett
I've just come to map a fingerpost, never having had cause to add one
previously.

To my surprise there is nothing on the wiki about how to do so, and I
can find no JSOM preset.

What do folk suggest?

I would like to add the inscription, for each of the three fingers,
with their comaps points, something like:

   inscription:NW=foo

or, using degrees:

   inscription:315:=foo

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


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

2020-07-16 Per discussione 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

2020-07-16 Per discussione 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


[Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-16 Per discussione Andrew Deng via Talk-ca
Hello, I believe Yonge Street in Toronto and York Region (Regional Road 1) 
should be tagged as highway=primary rather than highway=secondary as it is 
tagged now.
Here are some reasons I believe why:
1) Yonge Street is considered the "Main Street" of Toronto, Thornhill, Richmond 
Hill, and Aurora. It is also a major road in Newmarket.
2) It is a major thoroughfare throughout the route. In Toronto, the Yonge 
subway follows it and in York Region, Viva bus lanes are being built. It also 
connects to Bradford in the north.
3) It was a former Ontario King's Highway - Highway 11. Some other former 
King's Highways in the Toronto/York area are tagged as highway=primary, such as 
Highway 27, Highway 7, and Highway 48. 
--
 

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


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

2020-07-16 Per discussione 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


Re: [OSM-talk-fr] [HS mais pas trop] Référencer la production alimentaire locale

2020-07-16 Per discussione Jacques Lavignotte


Le 15/07/2020 à 20:34, chris-...@netcourrier.com a écrit :

J'avais pris le temps de regarder ceci il y a 1 an, et j'ai résumé ici :
https://wiki.openstreetmap.org/wiki/FR:WikiProject_CircularEconomy 




Pourquoi j'ai du mal avec ce «concept» d'Economie Circulaire » qui tente 
de nous faire croire que « Puisqu'on sait recycler (circulaire) on peut 
consommer/polluer/gaspiller »




J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Per discussione Matthew Woehlke

On 15/07/2020 21.16, Erwin Olario wrote:

Recently, some edits in the country came to the  attention of the community


When you say "the country", what country are we talking about?

I guess from context you mean "the Philippines", but you really ought to 
specify.


(I've been editing a bunch of stuff in PWC, Virginia, USA based partly 
on government data which I have been assured by the issuing agency is 
Public Domain. I *hope* you aren't talking about me, but it's really 
unclear.)


--
Matthew

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


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

2020-07-16 Per discussione 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

2020-07-16 Per discussione 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-ko] Seoul bike rental stations import

2020-07-16 Per discussione revi

KOGL has 4 types, 1 (equivalent of CC BY) / 2 (CC BY NC) / 3 (CC BY ND) / 4 
(CC BY NC ND).[1]

So, type 1 is basically similar to the CC BY license. Treat it like the CC BY.

[1]: https://www.kogl.or.kr/info/license.do#05-tab


revi
https://revi.omg.lol
나의 iPhone에서 보냄

> 2020. 7. 16. 22:27, Faustin Pegeot  작성:
> Hi,
> I noticed that the Seoul bike (따릉이) infrastructure near me was missing
> from OpenStreetMap. I managed to download the existing OSM data using
> https://overpass-turbo.eu/# (searching for tag amenity=bicycle_rental)
> and I found only 131 existing stations.
> 
> In parallel, I got official data from
> https://www.data.go.kr/data/15051893/fileData.do and they report 1540
> stations. The data is complete, with name, latitude, longitude, bike
> capacity and everything. I managed to load the whole data into a
> data-frame with Python and sanity-check it all and it all looks fine.
> For those who want to see it, I attached all the data on my GitHub @
> https://github.com/mistrpopo/osm_ddareungi/blob/master/osm_ddareungi_compare.txt
> 
> I am still in the process of comparing the two data sets to see
> whether they align well with the rest of the infrastructure (don't
> want to get bike stations in the middle of the street), but it looks
> promising so I want to start discussing the possibility of doing a
> mass import.
> 
> Regarding licencing compatibility, the data is licenced under :
> - CC-BY
> - KOGL (Korean Open Government Licence) type 1. (in Korean 공공누리)
> 
> From what I gathered, CC-BY is not fully compatible with OSM terms :
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
> 
> Regarding KOGL type 1, here is an english version of the licence :
> https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05
> 
> And here is a guide on licence compatibility for OGL-based licences :
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences
> 
> I don't have any experience with licences, so I am not sure where to
> continue from here. It sounds like we can use the data under KOGL
> licence (on the condition that we cite the source, which we will do
> under https://wiki.openstreetmap.org/wiki/Import/Catalogue ).
> 
> If not, I understand that I must require explicit permission. I also
> have the contact details for the Korean "Open Data Portal" :
> - tel :  공공데이터 개방문의 1566-0025
> - email : opendata_h...@nia.or.kr
> However, my Korean is sketchy and I am not sure whether they speak
> english, therefore if a native person could contact them, that would
> be great. I am not sure how many active users there are in Korea ...
> but if there are, please get in touch!
> 
> Thank you
> Faustin
> 
> ___
> Talk-ko mailing list
> Talk-ko@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ko
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko


Re: [Talk-ko] Seoul bike rental stations import

2020-07-16 Per discussione revi
KOGL has 4 types, 1 (equivalent of CC BY) / 2 (CC BY NC) / 3 (CC BY ND) / 4 
(CC BY NC ND).[1]

So, type 1 is basically similar to the CC BY license. Treat it like the CC BY.

[1]: https://www.kogl.or.kr/info/license.do#05-tab


revi
https://revi.omg.lol
나의 iPhone에서 보냄

> 2020. 7. 16. 22:27, Faustin Pegeot  작성:
> Hi,
> I noticed that the Seoul bike (따릉이) infrastructure near me was missing
> from OpenStreetMap. I managed to download the existing OSM data using
> https://overpass-turbo.eu/# (searching for tag amenity=bicycle_rental)
> and I found only 131 existing stations.
> 
> In parallel, I got official data from
> https://www.data.go.kr/data/15051893/fileData.do and they report 1540
> stations. The data is complete, with name, latitude, longitude, bike
> capacity and everything. I managed to load the whole data into a
> data-frame with Python and sanity-check it all and it all looks fine.
> For those who want to see it, I attached all the data on my GitHub @
> https://github.com/mistrpopo/osm_ddareungi/blob/master/osm_ddareungi_compare.txt
> 
> I am still in the process of comparing the two data sets to see
> whether they align well with the rest of the infrastructure (don't
> want to get bike stations in the middle of the street), but it looks
> promising so I want to start discussing the possibility of doing a
> mass import.
> 
> Regarding licencing compatibility, the data is licenced under :
> - CC-BY
> - KOGL (Korean Open Government Licence) type 1. (in Korean 공공누리)
> 
> From what I gathered, CC-BY is not fully compatible with OSM terms :
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
> 
> Regarding KOGL type 1, here is an english version of the licence :
> https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05
> 
> And here is a guide on licence compatibility for OGL-based licences :
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences
> 
> I don't have any experience with licences, so I am not sure where to
> continue from here. It sounds like we can use the data under KOGL
> licence (on the condition that we cite the source, which we will do
> under https://wiki.openstreetmap.org/wiki/Import/Catalogue ).
> 
> If not, I understand that I must require explicit permission. I also
> have the contact details for the Korean "Open Data Portal" :
> - tel :  공공데이터 개방문의 1566-0025
> - email : opendata_h...@nia.or.kr
> However, my Korean is sketchy and I am not sure whether they speak
> english, therefore if a native person could contact them, that would
> be great. I am not sure how many active users there are in Korea ...
> but if there are, please get in touch!
> 
> Thank you
> Faustin
> 
> ___
> Talk-ko mailing list
> Talk-ko@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ko
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko


Re: [Talk-ko] Seoul bike rental stations import

2020-07-16 Per discussione revi
KOGL has 4 types, 1 (equivalent of CC BY) / 2 (CC BY NC) / 3 (CC BY ND) / 4 (CC 
BY NC ND).[1]

So, type 1 is basically similar to the CC BY license. Treat it like the CC BY.

[1]: https://www.kogl.or.kr/info/license.do#05-tab


revi
https://revi.omg.lol
나의 iPhone에서 보냄

> 2020. 7. 16. 22:27, Faustin Pegeot  작성:
> 
> Hi,
> I noticed that the Seoul bike (따릉이) infrastructure near me was missing
> from OpenStreetMap. I managed to download the existing OSM data using
> https://overpass-turbo.eu/# (searching for tag amenity=bicycle_rental)
> and I found only 131 existing stations.
> 
> In parallel, I got official data from
> https://www.data.go.kr/data/15051893/fileData.do and they report 1540
> stations. The data is complete, with name, latitude, longitude, bike
> capacity and everything. I managed to load the whole data into a
> data-frame with Python and sanity-check it all and it all looks fine.
> For those who want to see it, I attached all the data on my GitHub @
> https://github.com/mistrpopo/osm_ddareungi/blob/master/osm_ddareungi_compare.txt
> 
> I am still in the process of comparing the two data sets to see
> whether they align well with the rest of the infrastructure (don't
> want to get bike stations in the middle of the street), but it looks
> promising so I want to start discussing the possibility of doing a
> mass import.
> 
> Regarding licencing compatibility, the data is licenced under :
> - CC-BY
> - KOGL (Korean Open Government Licence) type 1. (in Korean 공공누리)
> 
> From what I gathered, CC-BY is not fully compatible with OSM terms :
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
> 
> Regarding KOGL type 1, here is an english version of the licence :
> https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05
> 
> And here is a guide on licence compatibility for OGL-based licences :
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences
> 
> I don't have any experience with licences, so I am not sure where to
> continue from here. It sounds like we can use the data under KOGL
> licence (on the condition that we cite the source, which we will do
> under https://wiki.openstreetmap.org/wiki/Import/Catalogue ).
> 
> If not, I understand that I must require explicit permission. I also
> have the contact details for the Korean "Open Data Portal" :
> - tel :  공공데이터 개방문의 1566-0025
> - email : opendata_h...@nia.or.kr
> However, my Korean is sketchy and I am not sure whether they speak
> english, therefore if a native person could contact them, that would
> be great. I am not sure how many active users there are in Korea ...
> but if there are, please get in touch!
> 
> Thank you
> Faustin
> 
> ___
> Talk-ko mailing list
> Talk-ko@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ko
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko


Re: [Talk-GB] Scheduled Monument

2020-07-16 Per discussione Nick
Just wondering how this links to 
https://wiki.openstreetmap.org/wiki/Key:heritage - I was planning to use 
the tags detailed there together with the combinations.


On 16/07/2020 14:10, Tony OSM wrote:


Yes, maintenance when things change is an issue.

I've looked at taginfo listed_status and found several variations  for 
Scheduled Monument, Grade(value)


I plan to do several things if there are no objections

1. update wiki listed_status to show the capitalised values Scheduled 
Monument, Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site, Certificate of 
Immunity, Building Preservation Notice


https://wiki.openstreetmap.org/wiki/Key:listed_status

https://wiki.openstreetmap.org/wiki/Key:HE_ref

2. find those variations in the map in England and where I am sure 
amend the values of listed_status. I see this as a data cleansing 
exercise - there are about 20 elements.


Tony

On 16/07/2020 13:42, Nick wrote:


listed_status:website - URL seems to have changed from 
http://list.english-heritage.org.uk/resultsingle.aspx?uid=1409803 to 
https://historicengland.org.uk/listing/the-list/list-entry/1409803


On 16/07/2020 10:51, SK53 wrote:
It looks that for listed gardens we've used a combination of 
listed_status & listed_status_register (so each type belongs in a 
separate register): see Bagthorpe Gardens 
.


Mapping listed sties was a particular interest when Will & Richard 
Phillips created Evesham Mapped 
, 
so buildings and gardens are covered at least.


Jerry

On Wed, 15 Jul 2020 at 11:17, Brian Prangle > wrote:


I use listed_status =Scheduled Monument

On Wed, 15 Jul 2020, 10:19 Tony OSM, mailto:tonyo...@gmail.com>> wrote:

Whilst mapping some of my local historic places I have found
Scheduled Monuments. They are described in the Historic
England list as Heritage Category: Scheduled Monument and
has a List Entry Number.

Building are listed as Heritage Category: Listed Building ,
Grade: (I, II*, II) and a list entry number.

I can find tagging guidelines for a listed building but not
for Scheduled Monument or for any of the other Heritage
Categories (Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site,
Certificate of Immunity, Building Preservation Notice)

Can someone point me to the correct place for English
guidelines?

I have looked at:

https://wiki.openstreetmap.org/wiki/Key:listed_status

https://wiki.openstreetmap.org/wiki/Key:HE_ref

For a building or similar I presently use

HE_ref=1072653
heritage=2
heritage:operator= Historic England
historic= heritage
listed_status=Grade II
name= War Memorial Gateway to Astley Park
barrier=gate
start_date= mid C19

website=https://historicengland.org.uk/listing/the-list/list-entry/1072653

Could listed_status be expanded to hold the above definitions?


Tony Shield -  TonyS999

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

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


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


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


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


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

2020-07-16 Per discussione 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


[Talk-ko] Seoul bike rental stations import

2020-07-16 Per discussione Faustin Pegeot
Hi,
I noticed that the Seoul bike (따릉이) infrastructure near me was missing
from OpenStreetMap. I managed to download the existing OSM data using
https://overpass-turbo.eu/# (searching for tag amenity=bicycle_rental)
and I found only 131 existing stations.

In parallel, I got official data from
https://www.data.go.kr/data/15051893/fileData.do and they report 1540
stations. The data is complete, with name, latitude, longitude, bike
capacity and everything. I managed to load the whole data into a
data-frame with Python and sanity-check it all and it all looks fine.
For those who want to see it, I attached all the data on my GitHub @
https://github.com/mistrpopo/osm_ddareungi/blob/master/osm_ddareungi_compare.txt

I am still in the process of comparing the two data sets to see
whether they align well with the rest of the infrastructure (don't
want to get bike stations in the middle of the street), but it looks
promising so I want to start discussing the possibility of doing a
mass import.

Regarding licencing compatibility, the data is licenced under :
- CC-BY
- KOGL (Korean Open Government Licence) type 1. (in Korean 공공누리)

From what I gathered, CC-BY is not fully compatible with OSM terms :
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

Regarding KOGL type 1, here is an english version of the licence :
https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05

And here is a guide on licence compatibility for OGL-based licences :
https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences

I don't have any experience with licences, so I am not sure where to
continue from here. It sounds like we can use the data under KOGL
licence (on the condition that we cite the source, which we will do
under https://wiki.openstreetmap.org/wiki/Import/Catalogue ).

If not, I understand that I must require explicit permission. I also
have the contact details for the Korean "Open Data Portal" :
- tel :  공공데이터 개방문의 1566-0025
- email : opendata_h...@nia.or.kr
However, my Korean is sketchy and I am not sure whether they speak
english, therefore if a native person could contact them, that would
be great. I am not sure how many active users there are in Korea ...
but if there are, please get in touch!

Thank you
Faustin

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


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

2020-07-16 Per discussione 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-GB] POI files of Pub/Restaurant chain

2020-07-16 Per discussione Andy Townsend

On 16/07/2020 14:03, David Woolley wrote:

On 15/07/2020 14:00, o...@poppe.dev wrote:
As this data is pretty much openly accessible, I think there'd be no 
major issue with asking them if this data could be used to check all 
the places against OSM data and, if needed correct and/or create 
them, right?


I often find that business locations are way off target.  I think head 
offices often just plug the postcode into Google Maps, rather than 
asking someone to read them on their GPS capable mobile, or match them 
to actual features on the local map.


A quick check of one I know the location of shows that the co-ordinates 
given seem to be of the business park that its in rather than the 
building itself: https://www.openstreetmap.org/#map=19/53.22910/-1.42264 
.  That list should be OK for spotting missing examples, but if one is 
missing you'd need to visit to see which actual building it was in.  
Obviously a nominatim search of e.g. "harvester in chesterfield" will 
also return (or not) whatever OSM has.


Best Regards,

Andy


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


Re: [Talk-GB] Scheduled Monument

2020-07-16 Per discussione Tony OSM

Yes, maintenance when things change is an issue.

I've looked at taginfo listed_status and found several variations  for 
Scheduled Monument, Grade(value)


I plan to do several things if there are no objections

1. update wiki listed_status to show the capitalised values Scheduled 
Monument, Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site, Certificate of 
Immunity, Building Preservation Notice


https://wiki.openstreetmap.org/wiki/Key:listed_status

https://wiki.openstreetmap.org/wiki/Key:HE_ref

2. find those variations in the map in England and where I am sure amend 
the values of listed_status. I see this as a data cleansing exercise - 
there are about 20 elements.


Tony

On 16/07/2020 13:42, Nick wrote:


listed_status:website - URL seems to have changed from 
http://list.english-heritage.org.uk/resultsingle.aspx?uid=1409803 to 
https://historicengland.org.uk/listing/the-list/list-entry/1409803


On 16/07/2020 10:51, SK53 wrote:
It looks that for listed gardens we've used a combination of 
listed_status & listed_status_register (so each type belongs in a 
separate register): see Bagthorpe Gardens 
.


Mapping listed sties was a particular interest when Will & Richard 
Phillips created Evesham Mapped 
, 
so buildings and gardens are covered at least.


Jerry

On Wed, 15 Jul 2020 at 11:17, Brian Prangle > wrote:


I use listed_status =Scheduled Monument

On Wed, 15 Jul 2020, 10:19 Tony OSM, mailto:tonyo...@gmail.com>> wrote:

Whilst mapping some of my local historic places I have found
Scheduled Monuments. They are described in the Historic
England list as Heritage Category: Scheduled Monument and has
a List Entry Number.

Building are listed as Heritage Category: Listed Building ,
Grade: (I, II*, II) and a list entry number.

I can find tagging guidelines for a listed building but not
for Scheduled Monument or for any of the other Heritage
Categories (Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site,
Certificate of Immunity, Building Preservation Notice)

Can someone point me to the correct place for English
guidelines?

I have looked at:

https://wiki.openstreetmap.org/wiki/Key:listed_status

https://wiki.openstreetmap.org/wiki/Key:HE_ref

For a building or similar I presently use

HE_ref=1072653
heritage=2
heritage:operator= Historic England
historic= heritage
listed_status=Grade II
name= War Memorial Gateway to Astley Park
barrier=gate
start_date= mid C19

website=https://historicengland.org.uk/listing/the-list/list-entry/1072653

Could listed_status be expanded to hold the above definitions?


Tony Shield -  TonyS999

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

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


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


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


Re: [Talk-GB] POI files of Pub/Restaurant chain

2020-07-16 Per discussione osm
Hi Dave,

I got them from their website (harvester.co.uk/poi) and have done A LOT of 
additional things to create a GeoJSON, that I can import to MapRoulette, that 
would help engage the community.

I haven't gotten permission to use the data yet (have to send a snail-mail 
:-/), so please do not go and start adding data to OSM just yet, please.

Kai

> Dave F via Talk-GB  hat am 16. Juli 2020 um 14:53 
> geschrieben:
> 
> 
> Hi
> Did you obtain them from their website? If so, could you post the link?
> What's the content? Just location co-ordinates?
> 
> DaveF
> 
> On 15/07/2020 14:00, o...@poppe.dev wrote:
> > Hey all,
> >
> > I just accidentally found that the Pub next to "curious 20602512" is 
> > operated by a chain with quite a few places. They provide four different 
> > POI file formats with all their locations.
> >
> > As this data is pretty much openly accessible, I think there'd be no major 
> > issue with asking them if this data could be used to check all the places 
> > against OSM data and, if needed correct and/or create them, right?
> >
> > K
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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


Re: [Talk-GB] POI files of Pub/Restaurant chain

2020-07-16 Per discussione David Woolley

On 15/07/2020 14:00, o...@poppe.dev wrote:

As this data is pretty much openly accessible, I think there'd be no major 
issue with asking them if this data could be used to check all the places 
against OSM data and, if needed correct and/or create them, right?


I often find that business locations are way off target.  I think head 
offices often just plug the postcode into Google Maps, rather than 
asking someone to read them on their GPS capable mobile, or match them 
to actual features on the local map.


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


[Talk-GB] the first OSMUK microgrant

2020-07-16 Per discussione Jez Nicholson
You may be aware that OSMUK launched a microgrant scheme The first
awardee, Alex at Bexhill-OSM, has received a grant part-funding the
purchase of a camera for street level photography. Alex's dedication
building https://bexhill-osm.org.uk/ is no secret. This combined with being
able to monitor progress via Mapillary plus being able to do local OSM
outreach introducing local history groups to mapping through photography
ticked many boxes.

He's even got an eco-friendly electric scooter...
https://www.instagram.com/p/CCtBA-9HnBC/

- Jez
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] POI files of Pub/Restaurant chain

2020-07-16 Per discussione Dave F via Talk-GB

Hi
Did you obtain them from their website? If so, could you post the link?
What's the content? Just location co-ordinates?

DaveF

On 15/07/2020 14:00, o...@poppe.dev wrote:

Hey all,

I just accidentally found that the Pub next to "curious 20602512" is operated 
by a chain with quite a few places. They provide four different POI file formats with all 
their locations.

As this data is pretty much openly accessible, I think there'd be no major 
issue with asking them if this data could be used to check all the places 
against OSM data and, if needed correct and/or create them, right?

K

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



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


Re: [Talk-GB] Scheduled Monument

2020-07-16 Per discussione Nick
listed_status:website - URL seems to have changed from 
http://list.english-heritage.org.uk/resultsingle.aspx?uid=1409803 to 
https://historicengland.org.uk/listing/the-list/list-entry/1409803


On 16/07/2020 10:51, SK53 wrote:
It looks that for listed gardens we've used a combination of 
listed_status & listed_status_register (so each type belongs in a 
separate register): see Bagthorpe Gardens 
.


Mapping listed sties was a particular interest when Will & Richard 
Phillips created Evesham Mapped 
, 
so buildings and gardens are covered at least.


Jerry

On Wed, 15 Jul 2020 at 11:17, Brian Prangle > wrote:


I use listed_status =Scheduled Monument

On Wed, 15 Jul 2020, 10:19 Tony OSM, mailto:tonyo...@gmail.com>> wrote:

Whilst mapping some of my local historic places I have found
Scheduled Monuments. They are described in the Historic
England list as Heritage Category: Scheduled Monument and has
a List Entry Number.

Building are listed as Heritage Category: Listed Building ,
Grade: (I, II*, II) and a list entry number.

I can find tagging guidelines for a listed building but not
for Scheduled Monument or for any of the other Heritage
Categories (Protected Wreck Site,
Park and Garden, Battlefield, World Heritage Site, Certificate
of Immunity, Building Preservation Notice)

Can someone point me to the correct place for English guidelines?

I have looked at:

https://wiki.openstreetmap.org/wiki/Key:listed_status

https://wiki.openstreetmap.org/wiki/Key:HE_ref

For a building or similar I presently use

HE_ref=1072653
heritage=2
heritage:operator= Historic England
historic= heritage
listed_status=Grade II
name= War Memorial Gateway to Astley Park
barrier=gate
start_date= mid C19

website=https://historicengland.org.uk/listing/the-list/list-entry/1072653

Could listed_status be expanded to hold the above definitions?


Tony Shield -  TonyS999

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

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


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


Re: [OSM-talk-fr] Référencer la production alimentaire locale

2020-07-16 Per discussione Vincent Bergeot

Merci Christian,

Le 15/07/2020 à 20:34, chris-...@netcourrier.com a écrit :

Bonjour.

En complément :

J'avais pris le temps de regarder ceci il y a 1 an, et j'ai résumé ici :
https://wiki.openstreetmap.org/wiki/FR:WikiProject_CircularEconomy (paragraphe sur 
"produits alimentaires locaux")

Il y a plusieurs sites exemples, basés sur osm :

1. Marchés, magasins et distributeurs automatiques de produits alimentaires sur 
le site Web Farmshops.eu :
https://farmshops.eu
Tags utilisés :
shop=farm
amenity=vending_machine and tags supplémentaires vending=milk et vending=food
amenity=marketplace

2. Les marchés avec Wo ist markt :
https://wo-ist-markt.de/

Et si je résume :
Fermes qui font de la vente directe : shop=farm avec produce=* (ne pas utiliser 
product=* pour les produits peu ou pas transformés)
Bio : organic=yes and organic=only


ceux sont effectivement les mêmes tags.

j'ajouterai le landuse=farmyard même si cela concerne surtout des 
producteurs agricoles n'ayant pas forcément de point de vente 
(shop=farm) mais ayant par exemple une activité sur des marchés et/ou 
éventuellement sur rendez vous.


Encore merci






Christian

 Message d'origine 

De : Vincent Bergeot 
À : talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr]  Référencer la production alimentaire locale
Date : 15/07/2020 18:45:06 Europe/Paris

Bonjour,
je reprends le fil de cette discussion !

Le 05/02/2020 à 19:35, Vincent Bergeot a écrit :

pour référencer les lieux de productions alimentaires (les fermes en
particulier) et pour pouvoir "comparer" avec d'autres listes,
j'aimerai bien ajouter la ref siret, mais sur quel objet ?

Quand il y a un lieu de vente le shop=farm semble approprié (à voir si
il n'y a pas 2 siret différents,à creuser).

Mais quand il n'y a pas de lieu de vente !

Sur le farmyard ?
https://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dfarmyard

Le 05/02/2020 à 20:35, marc marc a écrit :

sur l'objet décrit par le siret :)
un office=company ou landuse=farmyard me semble bien

effectivement je n'avais pas imaginé office=company mais la ferme et
l'exploitation agricole se recoupe souvent donc je pense tendre vers
landuse=farmyard.



place=farm ne semble pas vraiment correspondre
(https://wiki.openstreetmap.org/wiki/Tag:place%3Dfarm)

taginfo / landuse=farmyard (plus de 800 000 occurrences) par rapport au
place=farm (un peu plus de 125 000).

donc c'est sans doute sur landuse=farmyard que le siret est le plus
approprié / le siret correspondant souvent à une EARL (exploitation
agricole à responsabilité limitée).

votre avis ?


--
Vincent Bergeot


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




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



--
Vincent Bergeot


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


Re: [Talk-it] Link Wikidata-OSM: no match

2020-07-16 Per discussione Jo
Ciao,

Hai provato di utilizzare il plugin Wikipedia de JOSM?

Polyglot

On Thu, Jul 16, 2020 at 11:32 AM Cascafico Giovanni 
wrote:

> Sto cercando di integrare in OSM eventuali biblioteche toscane
> presenti in Wikidata. Ho scaricato da WD con questa [1] query.
>
> Perchè, tra i diversi oggetti "no match", c'è anche questa [2]
> biblioteca? L'oggetto OSM è dalla parte opposta della piazza, ben
> entro il raggio di ricerca [3] della query che usa questo strumento di
> link
>
>
> [1] https://w.wiki/Wym
> [2] https://osm.wikidata.link/Q86537068
> [3] (around:1000,44.07872,10.09992)
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


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

2020-07-16 Per discussione 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

2020-07-16 Per discussione 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-GB] Scheduled Monument

2020-07-16 Per discussione SK53
It looks that for listed gardens we've used a combination of listed_status
& listed_status_register (so each type belongs in a separate
register): see Bagthorpe
Gardens
.

Mapping listed sties was a particular interest when Will & Richard Phillips
created Evesham Mapped
,
so buildings and gardens are covered at least.

Jerry

On Wed, 15 Jul 2020 at 11:17, Brian Prangle  wrote:

> I use listed_status =Scheduled Monument
>
> On Wed, 15 Jul 2020, 10:19 Tony OSM,  wrote:
>
>> Whilst mapping some of my local historic places I have found Scheduled
>> Monuments. They are described in the Historic England list as Heritage
>> Category: Scheduled Monument and has a List Entry Number.
>>
>> Building are listed as Heritage Category: Listed Building , Grade: (I,
>> II*, II) and a list entry number.
>>
>> I can find tagging guidelines for a listed building but not for Scheduled
>> Monument or for any of the other Heritage Categories (Protected Wreck Site,
>> Park and Garden, Battlefield, World Heritage Site, Certificate of
>> Immunity, Building Preservation Notice)
>>
>> Can someone point me to the correct place for English guidelines?
>>
>> I have looked at:
>>
>> https://wiki.openstreetmap.org/wiki/Key:listed_status
>>
>> https://wiki.openstreetmap.org/wiki/Key:HE_ref
>>
>> For a building or similar I presently use
>> HE_ref=1072653 heritage=2 heritage:operator= Historic England historic=
>> heritage listed_status=Grade II name= War Memorial Gateway to Astley Park
>> barrier=gate
>> start_date= mid C19 website=
>> https://historicengland.org.uk/listing/the-list/list-entry/1072653
>>
>> Could listed_status be expanded to hold the above definitions?
>>
>>
>> Tony Shield -  TonyS999
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[Talk-it] Link Wikidata-OSM: no match

2020-07-16 Per discussione Cascafico Giovanni
Sto cercando di integrare in OSM eventuali biblioteche toscane
presenti in Wikidata. Ho scaricato da WD con questa [1] query.

Perchè, tra i diversi oggetti "no match", c'è anche questa [2]
biblioteca? L'oggetto OSM è dalla parte opposta della piazza, ben
entro il raggio di ricerca [3] della query che usa questo strumento di
link


[1] https://w.wiki/Wym
[2] https://osm.wikidata.link/Q86537068
[3] (around:1000,44.07872,10.09992)

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


[Talk-TW] weeklyOSM #520 2020-06-30-2020-07-06

2020-07-16 Per discussione weeklyteam
台灣社群朋友好:
每週 OSM 新聞匯集文摘,# 520 期,如今已經發佈台灣華語版本,涵蓋開放街圖世界的大小事情!

https://www.weeklyosm.eu/zh/archives/13367/

歡迎閱讀!

你知道你能提供消息給 weeklyOSM 小組嗎?只要用 OSM 帳號登入 https://osmbc.openstreetmap.de/login 
就可以了。關於怎麼撰寫的方式請參閱:http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
誰:https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
那裡呢?:https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw


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

2020-07-16 Per discussione 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


Re: [talk-au] How do you tag a registered club?

2020-07-16 Per discussione Andrew Davidson

On 16/7/20 9:49 am, Bren Barnes wrote:
Morning, apparently it's amenity=licensed_club according to tagging 
guidelines.


https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Licensed_Club



Thanks for that. A lot less painful than I was expecting.

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


Re: [Talk-it] conferma utilizzo CTR Emilia Romagna in OSM

2020-07-16 Per discussione Lorenzo Stucchi
Ciao,

Credo che ci siano due aspetti da considerare: nella pagina wiki c’è scritto 
"La Regione Emilia Romagna ha concesso l'autorizzazione all'utilizzo della CTR 
raster per derivare dati di partenza per la zona del centro storico (dentro le 
mura).” Forse questa era la richiesta che era stata fatta, limitata a questo 
utilizzo, ma per questo servirebbe avere il testo della richiesta.

Il secondo aspetto mi chiedo se la carta non sia stata cambiata e non sia più 
quella del 2008 e magari ora ha una licenza diversa.

Ciao,
Lorenzo Stucchi

Il giorno 15 lug 2020, alle ore 21:38, Gianni G 
mailto:incrociatorepesa...@gmail.com>> ha 
scritto:

Salve a tutti,
sono un mappatore occasionale in e della Toscana, la quale ha autorizzato l'uso 
del geoscopio wms,
ora, passato il confine con l'Emilia stavo per utilizzare la CTR 5k della 
regione Emilia per ricalcare qualche fosso-corso d'acqua di montagna,
vedendo anche che su wiki sarebbe autorizzato l'uso per ricalco
Emilia Romagna  WMS CTR WMS 
CTR
[Utilizzabile in OSM] 
 
Aut.
   [Compatibilità sconosciuta] 
  Solo 
ricalcoRaster
https://wiki.openstreetmap.org/wiki/IT:Potenziali_fonti_di_dati

ma mi sono fermato poiché l'autorizzazione che vedo è del 2008 in riferimento 
ad una mappatura di Ferrara,
https://wiki.openstreetmap.org/wiki/Ferrara/Mapping_Party#Autorizzazione_Regione_Emilia-Romagna
anche se la risposta del funzionario regionale,
" Vista la Sua richiesta in data 4 aprile 2008 in merito alla pubblicazione di 
dati derivati dalla Carta tecnica regionale1:5000 nell'ambito del progetto 
OpenStreetMap si autorizza l'uso dei suddetti dati regionali, senza oneri di 
diritto all'uso"
sembra essere una liberatoria generale all'uso della CTR 5k in OSM,
è così?
Si può usare liberamente la CTR 5k wms dell'Emilia (licenza cc by) per 
ricalco-recupero informazioni in tutta l'Emilia e non solo per quel progetto di 
Ferrara?
Per quanto non credo proprio la regione Emilia avrebbe da obiettare sull'uso 
della sua ctr per derivarne dei fossi di montagna da inserire in OSM,
vorrei esserne sicuro.
Come la vedete?

Grazie
Gianni

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

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


[Talk-at] Autobahn Baukilometer

2020-07-16 Per discussione Philipp Kolmann

Hallo Liste,

weiss jemand, ob es eine Liste der Koordinaten für die Autobahn 
Baukilometer gibt. Ich arbeite an einem Programm für meine Feuerwehr, wo 
bei Alarmen ein PDF ausgedruckt wird, mit der Adresse.


Für Autobahnen habe ich aber kein Mapping der Baukilometer auf 
Positionen. Ich hab mir schon den Datensatz von gip.gv.at angeschaut, 
aber da hab ich auch keine Baukilometer gefunden.


Danke für Hinweise,
lg
Philipp

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


Re: [Talk-at] JOSM Adresshelfer Fehler:nullpointerexception

2020-07-16 Per discussione Philipp Kolmann

Hallo.

ich bin neu hier, hab mir aber das Problem vor ein paar Tagen angeschaut.

Am 15.07.2020 um 21:21 schrieb vari...@mailbox.org:
habs gerade mit JOSM 16731 ausprobiert, gleicher Fehler unter Linux. 
Aber es gibt auf Github bereits ein Issue dazu, da könnte man ja 
upvoten oder entsprechend ein Kommentar dazu abgeben, vielleicht wirds 
dann ja was. 


Das Problem ist, das der PostGIS Server von Thomas Konrad aktuell läuft. 
Thomas hat sowohl das Plugin geschrieben, betreibt aber auch die Backend 
Infrastruktur fürs Plugin.


Issue dafür ist bereits geöffnet:
https://github.com/JOSM/austriaaddresshelper/issues/12

Vielleicht hat jemand auf dieser Liste einen Kontakt zu Thomas und kann 
ihn fragen, was mit seinem Server los ist...


Ansich ist das API keine Hexerei. Ich hab mir das die Woche in der 
Arbeit angeschaut und den SQL Befehl in ein anderes Projekt eingebaut. 
Funktioniert ansich sehr gut.


lg
Philipp

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


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

2020-07-16 Per discussione 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