Re: [OSM-talk-nl] Boundaries in Curaçao

[dktue]

Hi Bas,

thanks for the quick response!

The admin_level=8-areas in Curacao have a source-tag that says 
"basiskaart.gobiernu.cw" which is actually a URL [1]. I couldn't open 
the map viewer nor could I find any information about the license. Maybe 
we should re-post our discussion in my newly opened thread in the forum 
(like you recommended) [2].


Cheers,
dktue

[1] http://basiskaart.gobiernu.cw/
[2] https://forum.openstreetmap.org/viewtopic.php?pid=775719

Am 30.01.2020 um 11:48 schrieb Bas Couwenberg:

On 2020-01-30 11:29, dktue wrote:

I'm looking at Curaçao and was checking the boundaries finding that
admin_level=8 seems to be pretty nicely tagged. But how can I find the
boundary of Willemstadt? Is there a consensus of how to use
admin_level=* in Curaçao?


Have you checked the history of boundary relations to see who edits 
them most frequently in recent years? This person is probably a good 
candidate to contact.


I only maintain the administrative boundaries (admin_level 10 and 
lower) within continental NL, I don't know anyone who does so for the 
overseas territories.


Looking at the enclosing features (via Query features on osm.org) it 
seems that there is no administrative boundary relation for 
Willemstadt, only a place node.


I'm not aware of any open data for Curaçao that could be used to add 
the city boundaries like the BAG in the Netherlands.


If such a dataset exists I'll consider also maintaining the boundaries 
of the overseas territories if they don't have a maintainer already.


For further discussion the forum is a better option as most active 
mappers are not on this list.


Kind Regards,

Bas


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



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

Re: [OSM-talk-nl] Boundaries in Curaçao

[Bas Couwenberg]

On 2020-01-30 11:29, dktue wrote:

I'm looking at Curaçao and was checking the boundaries finding that
admin_level=8 seems to be pretty nicely tagged. But how can I find the
boundary of Willemstadt? Is there a consensus of how to use
admin_level=* in Curaçao?


Have you checked the history of boundary relations to see who edits them 
most frequently in recent years? This person is probably a good 
candidate to contact.


I only maintain the administrative boundaries (admin_level 10 and lower) 
within continental NL, I don't know anyone who does so for the overseas 
territories.


Looking at the enclosing features (via Query features on osm.org) it 
seems that there is no administrative boundary relation for Willemstadt, 
only a place node.


I'm not aware of any open data for Curaçao that could be used to add the 
city boundaries like the BAG in the Netherlands.


If such a dataset exists I'll consider also maintaining the boundaries 
of the overseas territories if they don't have a maintainer already.


For further discussion the forum is a better option as most active 
mappers are not on this list.


Kind Regards,

Bas


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

[OSM-talk-nl] Boundaries in Curaçao

[dktue]

Hi there,

I'm looking at Curaçao and was checking the boundaries finding that 
admin_level=8 seems to be pretty nicely tagged. But how can I find the 
boundary of Willemstadt? Is there a consensus of how to use 
admin_level=* in Curaçao?


Cheers,
dktue

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

Re: [Talk-ko] boundaries

[Dongha Hwang]

+  https://www.openstreetmap.org/changeset/77488808#map=10/37.5566/125.1192
"ROK is possessing 12 nautical mile around Baengnyeong-do"
ᐧ

2019년 12월 20일 (금) 오후 9:31, Dongha Hwang 님이 작성:

> Sorry for the late response.
>
> User natureman did that edit, arguing "There is no island between
> Daecheong-do(대청도) and Yeonpyeong-do(연평도), so ROK doesn't possess the gap."
> However, Regarding my investigation, ROK argues that they must possess the
> area under 'Northern Limit Line'[2], but DPRK argues under 'Korea West Sea
> Maritime Military Demarcation line'[3].
>
> I think of this as an example of the disputed territory between two
> nations, but I've no idea about the situation...
>
> [1] https://www.openstreetmap.org/changeset/78538157
> [2] https://en.wikipedia.org/wiki/Northern_Limit_Line
> [3]
> https://ko.wikipedia.org/wiki/%EC%A1%B0%EC%84%A0_%EC%84%9C%ED%95%B4_%ED%95%B4%EC%83%81_%EA%B5%B0%EC%82%AC%EB%B6%84%EA%B3%84%EC%84%A0
> ᐧ
>
> 2019년 11월 27일 (수) 오후 9:12, 님이 작성:
>
>> Correction: The north WEST is looking strange.
>>
>> Regards
>>
>> walter
>> --
>> My projects:
>>
>> Admin Boundaries of the World 
>> Missing Boundaries
>> 
>> Emergency Map 
>> Postal Code Map (Germany only) 
>> Fools (QA for zipcodes in Germany) 
>> Postcode Boundaries of Germany
>> 
>> OSM Software Watchlist
>> 
>> ___
>> 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] boundaries

[Dongha Hwang]

Sorry for the late response.

User natureman did that edit, arguing "There is no island between
Daecheong-do(대청도) and Yeonpyeong-do(연평도), so ROK doesn't possess the gap."
However, Regarding my investigation, ROK argues that they must possess the
area under 'Northern Limit Line'[2], but DPRK argues under 'Korea West Sea
Maritime Military Demarcation line'[3].

I think of this as an example of the disputed territory between two
nations, but I've no idea about the situation...

[1] https://www.openstreetmap.org/changeset/78538157
[2] https://en.wikipedia.org/wiki/Northern_Limit_Line
[3]
https://ko.wikipedia.org/wiki/%EC%A1%B0%EC%84%A0_%EC%84%9C%ED%95%B4_%ED%95%B4%EC%83%81_%EA%B5%B0%EC%82%AC%EB%B6%84%EA%B3%84%EC%84%A0
ᐧ

2019년 11월 27일 (수) 오후 9:12, 님이 작성:

> Correction: The north WEST is looking strange.
>
> Regards
>
> walter
> --
> My projects:
>
> Admin Boundaries of the World 
> Missing Boundaries
> 
> Emergency Map 
> Postal Code Map (Germany only) 
> Fools (QA for zipcodes in Germany) 
> Postcode Boundaries of Germany
> 
> OSM Software Watchlist
> 
> ___
> 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

[Talk-ko] boundaries

[wambacher]

Correction: The north WEST is looking strange.

Regards

walter

--
My projects:

Admin Boundaries of the World 
Missing Boundaries 


Emergency Map 
Postal Code Map (Germany only) 
Fools (QA for zipcodes in Germany) 
Postcode Boundaries of Germany 
OSM Software Watchlist 

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

[Talk-ko] boundaries

[wambacher]

Hi,

the admin boundary of South Korea is looking strange. see 
https://www.openstreetmap.org/relation/307756

especially the north east .

regards
walter, germany

--
My projects:

Admin Boundaries of the World 
Missing Boundaries 


Emergency Map 
Postal Code Map (Germany only) 
Fools (QA for zipcodes in Germany) 
Postcode Boundaries of Germany 
OSM Software Watchlist 

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

[Talk-de] Boundaries Map 4.1 - Hilfe bei Übersetzung DE--> EN gesucht

[Walter Nordmann]

Hi,

ich habe die neue Release 4.1 der Boundaries Map fast fertig. Es hapert 
nur noch an der Übersetzung der deutschen Dokumentation ins Englische. 
Mein altes Schulenglisch wird wohl grausige Reaktionen bei 
Muttersprachlern und sonstigen Lesern hervorrufen wink


Wer mir ein wenig helfen mag - und nebenbei die Freigabe ermöglicht - 
möge sich bitte per PN, OSM-Mail oder sonstwie melden. Nur sollte das 
"privat" sein, da ich erst die fertige Doku freigeben will.


Es handelt sich um einen Multi-User-Pad, wo man ohne Registrierung 
einfach loslegen kann. Very easy.


Textlänge: ca 2 Seiten.

Natürlich bin ich auch noch am Übersetzen, aber manche Sachen fallen mir 
einfach schwer.


Danke und Gruss
walter

ps: Kopie aus dem Forum, da die Resonanz dort äusserst dürftig war. Hier 
könnt ihr es besser machen ;)


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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Greg Troxel]

Martijn van Exel m...@rtijn.org writes:

 On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us
 wrote:

 If you're lucky, you can find an Ohio city limit's legal definition in
 county commissioners' minutes when an annexation is proposed. The most
 authoritative data representation is the county GIS database, which anyone
 can easily access -- for a fee. After paying the county for that database,
 you might well forget about OSM, because it's also the authoritative source
 for road centerlines and names.

 That is actually not what I meant, but I could have been more precise. I
 guess this turns into a discussion of what 'authoritative' actually means.
 This is different things to different people. As OSM becomes better,
 increasingly folks will start looking at us for authoritativeness, which
 would make sense because everything is (supposed to be) verified on the
 ground.

authoritative is a complicated word.   One sense is the source that
legally defines something.   The other sense is what people usually mean
with maps, which is about whether the map production process is such
that a user can have a high degree of confidence 

 Because administrative boundaries have legal implications, the
 authoritative source will need to be someplace outside of OSM.

True, but I don't see the point.  The authoritative source for whether a
road exists is the fact in the real world, so that's outside OSM too.  A
map (database; that's not the point here) is a collection of useful
facts, and except for maps published by entities whose word defines the
world, no maps are authoritative in this sense.

It's certainly true that no court would decide if a house is in a
particular town by looking at OSM.  I'm not sure if you're suggesting
deleting all the boundary data, or just pointing out that most court
cases will not use OSM data, or something else.

 It may actually hurt OSM down the line if we include information that
 suggests authoritativeness we cannot provide.

I really don't follow your logic here.  OSM has all sorts of
information, and is the authoritative-as-defining source for essentially
none of it.  This is true of arguably every general-purpose map.  Even
the USGS map includes information where the Board of Geographic Names is
authoritative.

When I hear regular GIS people talk about authoritative data in the
context of OSM, the concern is that anyone can edit and there is no QA
process, so how can the data be trusted?  This is compared to NAVTEQ
(just to pick on), which presumably takes State DOT data and surveys/QAs
it (so how can the data be up to date?).  Whether the crowdsourcing
process or the standard process leads to better data is not a settled
question; there are valid arguments about the process both ways.  (I
find OSM data to be generally better in Massachusetts than e.g. the
proprietary data that comes with a Nuvi, but in some places it's worse.)

With respect to boundaries, careful curation of boundary information
(from the law, as Minh suggests, or actual stones in my state) by OSM
people leads to a good set of data, arguably as good as included in any
other general-purpose map.  So it's just the usual grand struggle to
improve and add data, and I don't see why there should be any special
concerns about authoritativeness.

  All of this has little to do with neighborhoods, which are mostly (?)
 vernacular in naming and delineation, and even when there are official
 neighborhood designations, in my own experience they do not always match
 the vernacular names. I support point mapping of vernacular
 neighborhoods. If you really want to have shapes for vernacular
 neighborhoods, you can look at the now-ancient-but-still-cool flickr
 Alpha Shapes[2], last updated in 2011 but still available for
 download[3]. But please don't upload 'em to OSM :)


 As a political boundary (in the political map sense), an official
 neighborhood designation can be distinct from the neighborhood with a
 vernacular name, but that's an argument to map both rather than favoring
 one over the other. They coexist and might share a name but aren't
 necessarily the same thing. People should be able to get the concrete,
 objective boundary of an official neighborhood from OSM and an amorphous,
 subjective boundary of an informal neighborhood from Alpha Shapes.

 Sure, but vernacular and official neighborhood objects would then need to
 be represented differently so folks can tell them apart and know what they
 are dealing with.

That's basically admin_level=10 for an official neighborhood (I think
Boston and Newton have these), and some sort of place=locality for
things without legal boundaries.

This is related to the hamlet discussion.  One of the issues with OSM's
place name schema is the confusion between place names and boundaries.
Boundaries are actually pretty clear how they should be.  But the
place=town etc. talk about population, and you can't have population
without a boundary.  That probably 

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Russ Nelson]

Serge Wroclawski writes:
  It's entirely possible that the names the locals use for that river
  differ from the  government dataset, in which case, OSM would prefer
  you use the local name as the primary name, and not the official one.

This is the USGS standard for naming in their topo maps.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Martijn van Exel]

On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us
wrote:

 On 2015-03-24 13:57, Martijn van Exel wrote:

 I have long been on the fence about boundaries in OSM, and while I don't
 feel as strongly about it any longer, it still feels wrong to make this
 sweeping exception to one of the fundamental conventions of OSM mapping:
 verifiability. For many types of land use, anyone would be able to
 verify boundaries on the ground: a forest, a corn field, even a retail
 zone in most cases. But administrative boundaries can only be observed
 in a limited number of places: wherever there is a sign or a physical
 boundary in place, and rare other cases.


 Admittedly, a given border can be observable along one segment but not
 another. However, we tend to map the entire border for the sake of
 completeness, convention, and technical reasons -- closed areas are much
 more useful than stray lines. OSM has long gone to extremes on this point,
 going so far as to enclose all continents and island nations in maritime
 borders.

 Hopefully you had the chance to read my case study on Illinois, Indiana,
 Ohio, Kentucky, and West Virginia earlier in this thread. [1] You can
 observe much of the Ohio-Indiana state line quite precisely, both on the
 ground via welcome signs and mile markers and from the air via changes in
 land use and pavement quality. But you cannot observe the Ohio-Kentucky
 state line except by visiting a library, and the Ohio-Ontario border is an
 imaginary line. Which of the five options would you have chosen for Ohio?

 [1] https://lists.openstreetmap.org/pipermail/talk-us/2015-
 March/014485.html


I have, and my (admittedly much more limited) experience in Utah does not
suggest I would be able to determine a reliable state boundary from
information on the ground. County lines even much less so.



  More importantly though, there is an authoritative source for
 official administrative boundaries that can be easily accessed by
 anyone: TIGER[1]


 You mean the way TIGER is an authoritative source for road centerlines?
 TIGER's boundaries vary in quality just as its roads and railroads do. I've
 taken quite a few imported municipal boundaries, lined them up with road
 easements or hedges between farms _when that is obviously the intent_, and
 deleted extra nodes. These borders become far more accurate and precise in
 OSM than in commercial maps, which regurgitate TIGER boundaries verbatim.


 The most authoritative source for most U.S. land borders, going all the
 way down to the parcel level, is a legal prose definition in conjunction
 with any number of monuments on the ground. Both metes and bounds and the
 Public Land Survey System rely on monumentation. A monument may be a major
 road or as obscure as a small iron pin embedded in that road, but even that
 pin is verifiable if not particularly armchair-mappable.


 If you're lucky, you can find an Ohio city limit's legal definition in
 county commissioners' minutes when an annexation is proposed. The most
 authoritative data representation is the county GIS database, which anyone
 can easily access -- for a fee. After paying the county for that database,
 you might well forget about OSM, because it's also the authoritative source
 for road centerlines and names.


That is actually not what I meant, but I could have been more precise. I
guess this turns into a discussion of what 'authoritative' actually means.
This is different things to different people. As OSM becomes better,
increasingly folks will start looking at us for authoritativeness, which
would make sense because everything is (supposed to be) verified on the
ground. Because administrative boundaries have legal implications, the
authoritative source will need to be someplace outside of OSM. It may
actually hurt OSM down the line if we include information that suggests
authoritativeness we cannot provide.




  All of this has little to do with neighborhoods, which are mostly (?)
 vernacular in naming and delineation, and even when there are official
 neighborhood designations, in my own experience they do not always match
 the vernacular names. I support point mapping of vernacular
 neighborhoods. If you really want to have shapes for vernacular
 neighborhoods, you can look at the now-ancient-but-still-cool flickr
 Alpha Shapes[2], last updated in 2011 but still available for
 download[3]. But please don't upload 'em to OSM :)


 As a political boundary (in the political map sense), an official
 neighborhood designation can be distinct from the neighborhood with a
 vernacular name, but that's an argument to map both rather than favoring
 one over the other. They coexist and might share a name but aren't
 necessarily the same thing. People should be able to get the concrete,
 objective boundary of an official neighborhood from OSM and an amorphous,
 subjective boundary of an informal neighborhood from Alpha Shapes.


Sure, but vernacular and official neighborhood 

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Bryce Nesbitt]

On Wed, Mar 25, 2015 at 2:00 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us
wrote:

 I've taken quite a few imported municipal boundaries, lined them up with
 road easements or hedges between farms _when that is obviously the intent_,
 and deleted extra nodes. These borders become far more accurate and precise
 in OSM than in commercial maps, which regurgitate TIGER boundaries verbatim.

 The most authoritative source for most U.S. land borders, going all the
 way down to the parcel level, is a legal prose definition in conjunction
 with any number of monuments on the ground.


Ah, another sticky wicket.

There are many defacto boundaries created by roads, hedges, powerlines,
ridges or bodies of water.

I argue the most appropriate boundary in OSM is indeed the defacto
boundary.  If people are using, paving, weeding
and farming the boundary, that's the one we can map.

The legal boundary is not something OSM can adjudicate.  Finding that
boundary is a complex process involving survey points, land descriptions,
and often handwritten records stored in dark basements.  It also hardy ever
matters, at least to a mapper or map reader.



Note that in the USA boundaries are determined by reference to written
deeds, and subject to challenge in court.  Various non-registered rights,
including right of passage, may exist.  It's a huge mess.

In Australia, as I understand, land ownership is a matter of public record,
and all ownership changes must be registered. The government records are,
by definition, correct.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Kevin Kenny]

On 03/23/2015 12:29 PM, Bryce Nesbitt wrote:

The nice thing about mapping a neighborhood name as a point feature is:

a) It helps people locate the neighborhood
b) it completely sidesteps the question of the exact, possibly fuzzy, 
boundaries.


For 10% of the hassle you map 90% of the benefit.


Or follow the obvious rule:  Let the local mappers decide.

Use point features for indeterminate things.

In areas where neighborhoods have borders that are identifiable on the 
ground, map the borders. Some neighborhoods are gated. Some are signed. 
Some, all the locals understand, are bounded by major streets. Many 
subdivisions, even if not signed, have homogeneous enough architecture 
that the borders are obvious. And some cities try to foster neighborhood 
identity and specifically identify neighborhoods, even where the 
neighborhoods are not legal political entities.


Don't decide as an armchair mapper that you know better than the locals. 
This goes double for using a mechanical edit to fix what the locals 
have done. Fix only what you can see is wrong on the ground (or what you 
can't see on the ground at all). This sort of fixing requires boots on 
the ground. (I'm willing to allow an exception for repairing the damage 
done by ill-advised mechanical edits - but only after consultation with 
the locals.)


--
73 de ke9tv/2, Kevin


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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Jack Burke]

I would politely disagree that TIGER is an authoritative source for two reasons:

1) The extensive TIGER cleanup that is still being done years after the last 
import, and

2) While helpful at compiling data, the federal government is not authoritative 
for any boundaries within a state (and once established, not even for the 
boundaries of the states themselves).

-jack

On March 24, 2015 4:57:44 PM EDT, Martijn van Exel mart...@openstreetmap.us 
wrote:
 there is an
authoritative
source for official administrative boundaries that can be easily
accessed
by anyone: TIGER

-- 
Typos courtesy of fancy auto-spell technology. 

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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Richard Welty]

On 3/24/15 6:01 PM, Jack Burke wrote:
 I would politely disagree that TIGER is an authoritative source for two 
 reasons:

 1) The extensive TIGER cleanup that is still being done years after the last 
 import, and
well, if that data were removed and sourced externally, the problems
with TIGER boundary
data and OSM would change in character rather substantially.
 2) While helpful at compiling data, the federal government is not 
 authoritative for any boundaries within a state (and once established, not 
 even for the boundaries of the states themselves).
as part of the ongoing improvements in TIGER, the Census Bureau is
increasingly pulling data from County GIS departments rather than
maintaining it themselves. the quality is much better. and since it's
digital, the game of telephone metaphor does not apply so much any
more.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS  IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Clifford Snow]

On Tue, Mar 24, 2015 at 7:46 AM, Kevin Kenny kken...@nycap.rr.com wrote:

 Or follow the obvious rule:  Let the local mappers decide.

 Use point features for indeterminate things.

 In areas where neighborhoods have borders that are identifiable on the
 ground, map the borders. Some neighborhoods are gated. Some are signed.
 Some, all the locals understand, are bounded by major streets. Many
 subdivisions, even if not signed, have homogeneous enough architecture that
 the borders are obvious. And some cities try to foster neighborhood
 identity and specifically identify neighborhoods, even where the
 neighborhoods are not legal political entities.

 Don't decide as an armchair mapper that you know better than the locals.
 This goes double for using a mechanical edit to fix what the locals have
 done. Fix only what you can see is wrong on the ground (or what you can't
 see on the ground at all). This sort of fixing requires boots on the
 ground. (I'm willing to allow an exception for repairing the damage done by
 ill-advised mechanical edits - but only after consultation with the locals.)


+1


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Martijn van Exel]

I have long been on the fence about boundaries in OSM, and while I don't
feel as strongly about it any longer, it still feels wrong to make this
sweeping exception to one of the fundamental conventions of OSM mapping:
verifiability. For many types of land use, anyone would be able to verify
boundaries on the ground: a forest, a corn field, even a retail zone in
most cases. But administrative boundaries can only be observed in a limited
number of places: wherever there is a sign or a physical boundary in place,
and rare other cases. More importantly though, there is an authoritative
source for official administrative boundaries that can be easily accessed
by anyone: TIGER[1]

All of this has little to do with neighborhoods, which are mostly (?)
vernacular in naming and delineation, and even when there are official
neighborhood designations, in my own experience they do not always match
the vernacular names. I support point mapping of vernacular neighborhoods.
If you really want to have shapes for vernacular neighborhoods, you can
look at the now-ancient-but-still-cool flickr Alpha Shapes[2], last updated
in 2011 but still available for download[3]. But please don't upload 'em to
OSM :)

[1] https://www.census.gov/geo/maps-data/data/tiger-cart-boundary.html
[2] http://code.flickr.net/2008/10/30/the-shape-of-alpha/
[3] http://code.flickr.net/2011/01/08/flickr-shapefiles-public-dataset-2-0/

Martijn van Exel
Secretary, US Chapter
OpenStreetMap
http://openstreetmap.us/
http://osm.org/
skype: mvexel

On Mon, Mar 23, 2015 at 11:39 AM, Clifford Snow cliff...@snowandsnow.us
wrote:


 On Mon, Mar 23, 2015 at 10:29 AM, Bryce Nesbitt bry...@obviously.com
 wrote:

 The nice thing about mapping a neighborhood name as a point feature is:

 a) It helps people locate the neighborhood
 b) it completely sidesteps the question of the exact, possibly fuzzy,
 boundaries.

 For 10% of the hassle you map 90% of the benefit.


 Except when it reports you are in a different neighborhood than you
 actually are. When neighborhoods are not clearly defined then yes, a point
 is the best choice. But when neighborhoods have defined boundaries then
 they should be added. Just going up the admin level to city level, points
 work until it says you are in a different city. We can not see city
 boundaries but OSM has thousands of city boundaries. The simple solution is
 if the neighborhood boundaries are clearly defined they belong in OSM as
 polygons. If neighborhood boundaries are not clearly defined then they
 should be represented by points.

 For the supporters of no admin boundaries in OSM, build the case on the
 mailing lists instead of just saying there is a growing support for no
 boundaries. In some parts of the US there is a growing support that climate
 change is a hoax. That doesn't make it true. Build a case for removing
 admin boundaries (and please include landuse.)

 Ideally in the future we can have a fuzzy boundary. But until then I think
 what I proposed is an acceptable solution.

 Clifford


 --
 @osm_seattle
 osm_seattle.snowandsnow.us
 OpenStreetMap: Maps with a human touch

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


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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Frederik Ramm]

Greg,

 3. It is my belief and experience that the ground observable rule is
 something that only applies to Europe or older metropolitan areas.

I think there's a misunderstanding here.

Of course even in European metropolitan areas there will *not* be a sign
bearing the name of every stream that you drive across! That doesn't
keep Europeans from mapping the stream (the fact that there *is* one is
at least observable), or naming it according to common knowledge or
whatever the locals will tell you the name is.

We usually draw the line when it is about features that cannot be seen
on the ground; these should be in OSM only in exceptional cases (for
example we do map administrative boundaries and post code areas even if
they're invisible; the discussion about how much of a railway must still
be there to map it as abandoned is going on elsewhere; the mapping of
airways is strongly discouraged; some people map long-distance radio
links but that is not likely to catch on).

Your remark that OSM is different from the old GIS world with ESRI and
$20k GPS receivers is correct, however it is not a suitable basis for
reasoning (following the same logical path as you did, I could say they
use computers; we are different, so we should not use computers).

The ground observable rule kicks in most strongly when there's a
dispute. If one mapper happily maps an invisible boundary and another
mapper pops up and maps it differently, and they later apply to someone
to mediate in their conflict, that third person will ask whether there
is any proof for each mapper's version, and if there isn't any because
both just map from hearsay, then the feature will have to be tagged as
disputed or removed altogether.

 9. Taking Serge's example of neighborhood boundaries to the logical
 conclusion, nothing should be put in OSM because an edit war __could__
 ensue.

Again, you've misunderstood Serge; because as long as we stick to
observable things, the edit war can be resolved by fact-checking.

This is what Serge hinted at when he talked about Alice and Bob.
Crucially he also mentioned that there's a high risk that if we allow
un-substantiated mapping of neighbourhoods, this might be at the expense
of the underprivileged who seldom participate in OSM. For some, it might
make a very big difference whether their address resolves to
neighbourhood A or neighbourhood B if they live just on the border. As
long as we're talking facts there's not much that can go wrong - an
able-bodied, college-educated caucasian male can trace a stream through
the slums from Bing without being in much danger of unwittingly applying
prejudice. The same is not true for the same able-bodied,
college-educated caucasian male drawing the boundary of the
neighbourhood they are unlikely to ever set foot in.

There's actually quite a few things apart from neighbourhoods that are
not defined. For example here in Germany, if a village can advertise
themselves as being in the Black Forest, that's a plus, tourism-wise.
But the Black Forest is not a forest where you simply check the
treeline; it's a large region with not-really-well-defined boundaries.
There's places where 99% of interviewees would says clearly that's in
the Black Forest, and places where 99% would say clearly not, but a
grey band in between. The kind of area that is labelled with a curved,
wide-spaced font on old-school maps. OSM doesn't have a good mechanism
to record these; OSM only accepts precise geometries, not fuzzy ones.

 7. The ground observable rule is a barrier to new mappers. I helped a
 new mapper at a Editathon add taco stands.  She did everything wrong. I
 did say no you cannot add that node. We have not gone and surveyed that
 node exists.  I let her add the node with abbreviated street names and
 all.  She was so exited to add here research data to OSM.

There's absolutely no problem with adding Taco stands from memory as
they are observABLE (even if not observED) and if someone else starts a
fuss about the Taco stands, we can just go there and check.

People add data from memory all the time, and if it's wrong, it get
fixed. But that's not the point when discussing neighbourhood boundaries.

 I failed to
 map for months because it sounded like I had to have a GPS five years
 ago before I could map.

I think you're consistently misunderstanding the difference between
observable and observed.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Richard Fairhurst]

Greg Morgan wrote:
 2. To quote Richard Fairhurst, Seriously, OSM in the [England] s still 
 way beyond broken.  You can open it at any random location and the map 
 is just __fictional__. Here are two random examples bing;OS StreetView  
 [2] shape is approximate. Needs proper survey as mostly built after 
 current BING imagery date [3]

I have no idea, at all, what point you are trying to make, but I would
appreciate it if you didn't make it by deliberately misquoting me. Thank
you.

Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Retagging-hamlets-in-the-US-tp5837186p5838190.html
Sent from the USA mailing list archive at Nabble.com.

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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Serge Wroclawski]

On Mon, Mar 23, 2015 at 2:30 AM, Greg Morgan dr.kludge...@gmail.com wrote:

 1. Every time this boundary debate or accuracy debate comes up, I image that
 I am supposed to have $20,000 of GPS equipment[1]; post process the data so
 that it is accurate; before I dare put the data in OSM.

I agree with you that things which you can't verfiy without thousands
of dollars of equipment doesn't belong in a generalized dataset like
OSM.

 3. It is my belief and experience that the ground observable rule is
 something that only applies to Europe or older metropolitan areas.

Then you're going to have problems with all of OSM, since we use that rule
to handle virtually any dispute.

  I am curios what river or wash I just drove
 over.  It is not posted.  I had to go to the US government sites to find the
 information because it is useful in OSM.

It's entirely possible that the names the locals use for that river
differ from the  government dataset, in which case, OSM would prefer
you use the local name as the primary name, and not the official one.
Ground observable in this case is Local knowledge. Of course that
requires consensus, but this is why we have so many tags related to
names

 6. The ground observable rule is trying to take over the more important
 rule: Mappers with local knowledge of their area add valuable data that
 commercial mapping companies cannot always afford to add to the map.

This is based on a misunderstanding of your understanding of what the
ground observable rule is. A person who lives in an area and can talk
about it will actually trump most other sources, including signage,
but that requires that we get lots of people involved and working in a
diplomatic way.

 7. The ground observable rule is a barrier to new mappers. I helped a new
 mapper at a Editathon add taco stands.  She did everything wrong. I did say
 no you cannot add that node. We have not gone and surveyed that node exists.
 I let her add the node with abbreviated street names and all.  She was so
 exited to add here research data to OSM.

Why not help her ensure that her data be in OSM by being a teaching resource?

Also, what does sign names have to do with ground surveying?

 8. The ground observable rule is a barrier to new mappers. Most of the new
 mappers I know started mapping by signing up and adding data.

Adding data they surveyed or adding data they got from another source?

 9. Taking Serge's example of neighborhood boundaries to the logical
 conclusion, nothing should be put in OSM because an edit war __could__
 ensue.

This is quite the stawman argument you've build in my name, but it's
not my argument.

OSM has a long history of encouraging surveyed data.

 11. The ground observable rule fails to acknowledge that not every feature
 is observable but still is useful to OSM.  I had to talk the rent-a-cops out
 of arresting me for taking pictures around Chase Field [8]. I could not see
 around the building or under the 7th street bridge via satellite imagery. In
 this post 911 world, the ground observable rule is an unrealistic
 requirement.

I've never encountered a problem with law enforcement officials when
mapping, so I can't speak to your experience.

 12.I am passionate about what I do with OSM and the out reach that I do.  I
 am game to survey and map my city, county, and state.  It feels like this
 growing number of people believes that every mapper has to map just like
 Steve Coast did ten years ago. Congratulations Serge!  It is my growing
 belief that your growing number of people has stymied growth in new and
 different valuable ways of mapping data.  I failed to map for months because
 it sounded like I had to have a GPS five years ago before I could map.

Last year (or was it the year before) at SOTM US, there was discussed
with Ian Dees leading the discussion about using municipal data in a
separate dataset, and yet I don't see you being as viscous against
him.

Whether it's deliberate or not, please stop misquoting me to further
your arguments.

- Serge

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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Serge Wroclawski]

I agree 100% with Bryce.

- Serge

On Mon, Mar 23, 2015 at 12:29 PM, Bryce Nesbitt bry...@obviously.com wrote:
 The nice thing about mapping a neighborhood name as a point feature is:

 a) It helps people locate the neighborhood
 b) it completely sidesteps the question of the exact, possibly fuzzy,
 boundaries.

 For 10% of the hassle you map 90% of the benefit.

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


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

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Greg Morgan]

On Sun, Mar 22, 2015 at 2:04 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us
wrote:

 tl;dr: I'm against a blanket rule when it comes to administrative
 boundaries. They're really nuanced, and so should we.

 On 2015-03-22 04:32, Serge Wroclawski wrote:

 Imagine if Bob and Alice conflict on where a neighborhood boundary is
 inside OSM. The issue escalates to an edit war and the DWG is called
 in to resolve the conflict. Let's say that Frank is our DWG member.
 How is Frank supposed to resolve the conflict between Alice and Bob?
 Often neighborhoods don't have administrative recognition, or
 administrative recognition is not in alignment with the people. I
 imagine this would be especially an issue with neighborhoods where
 lots of the under-represented populations live.


 This is an important consideration. As I mentioned in a footnote earlier,
 even a city with strong neighborhood organization can have boundary
 disputes. However, the problem exists for administrative boundaries in
 general, all the way up to admin_level=2 boundaries that cut right across
 ethnic fault lines.

 My point was that we should map neighborhood boundaries in cities where
 doing so requires little editorial judgment, thanks to signage, distinctive
 lamp posts, etc. And we are quite clear (via the tag value
 administrative) that this isn't the only way by which a community can be
 delimited. As numerous threads have pointed out, the USPS has very
 different ideas of location (ZIP codes), but that's OK.

 When it comes to all our discussions around *administrative* boundaries, I
 like this two-point test as a rule of thumb:

 1. Are people or property governed differently on one side versus the
 other?

 2. Is this distinction observable on the ground?

 Municipalities generally pass both points. Congressional districts pass #1
 but not #2. CDPs generally fail both. School districts can be observed, but
 not with the granularity required for mapping a boundary. City
 neighborhoods may pass one, both, or neither. Maybe all the locals you
 interview can agree on the name of a neighborhood but not its shape -- in
 which case it should be nothing more than a POI.

 Which brings me to Serge's other point:

  First, there are a growing number of people who believe that
 administrative data is very useful, but breaks OSM's ground
 observable rule. That is, someone who is present on the ground should
 be able to observe the data in OSM. It's usually not possible to do
 that with administrative boundaries.


 SteveA has responded more forcefully on this point, and so have I in the
 past. [1] Fortunately, Alice and Bob's disagreement sounds pretty
 clear-cut. If the city didn't go through the trouble of demarcating any
 part of the boundary in some way, perhaps the general public shouldn't
 expect OSM to reproduce their two neighborhoods' boundaries at all. But I
 see no reason why such a decision would impact boundaries with very
 different characteristics.



tl;dr: I'm against blanket rules especially when they don't reflect the
realities of the world or how far we have come in ten years.  These rules
prevent progress and new ways of thinking about solutions.  Imagine the
changes OSM, OpenLayers, Leafet, MapBox have made.  The ESRI rule said that
we shouldn't do it that way.  You should spend large amounts of money to do
GIS things. Based on my ESRI analogy, the ground observable rule feels
like using ArcGIS Desktop to do mapping.  Is that a reality anymore?  In
actuality, the OSM and ESRI way complement each other and can be used
together.

1. Every time this boundary debate or accuracy debate comes up, I image
that I am supposed to have $20,000 of GPS equipment[1]; post process the
data so that it is accurate; before I dare put the data in OSM.

2. To quote Richard Fairhurst, Seriously, OSM in the [England] s still way
beyond broken.  You can open it at any random location and the map is just
__fictional__. Here are two random examples bing;OS StreetView  [2] shape
is approximate. Needs proper survey as mostly built after current BING
imagery date [3]  I thought Bing was so bad that it is broken.  What is
happening with this growing number of people is they say or imply that
England, the birth place of OSM, is the bee's knees for accuracy because it
was surveyed the old fashioned way.  I find no difference in these two
examples in England than adding an approximate area in the US based on a
subdivision or some other locally named area.

3. It is my belief and experience that the ground observable rule is
something that only applies to Europe or older metropolitan areas.
There's a number of times that I have read on the US list that either the
signs are missing, stolen, or never posted.  One of the reasons I map what
I do is because the signs are missing.  I am curios what river or wash I
just drove over.  It is not posted.  I had to go to the US government sites
to find the information because it is useful in OSM.  So what do you want

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Bryce Nesbitt]

The nice thing about mapping a neighborhood name as a point feature is:

a) It helps people locate the neighborhood
b) it completely sidesteps the question of the exact, possibly fuzzy,
boundaries.

For 10% of the hassle you map 90% of the benefit.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Clifford Snow]

On Mon, Mar 23, 2015 at 10:29 AM, Bryce Nesbitt bry...@obviously.com
wrote:

 The nice thing about mapping a neighborhood name as a point feature is:

 a) It helps people locate the neighborhood
 b) it completely sidesteps the question of the exact, possibly fuzzy,
 boundaries.

 For 10% of the hassle you map 90% of the benefit.


Except when it reports you are in a different neighborhood than you
actually are. When neighborhoods are not clearly defined then yes, a point
is the best choice. But when neighborhoods have defined boundaries then
they should be added. Just going up the admin level to city level, points
work until it says you are in a different city. We can not see city
boundaries but OSM has thousands of city boundaries. The simple solution is
if the neighborhood boundaries are clearly defined they belong in OSM as
polygons. If neighborhood boundaries are not clearly defined then they
should be represented by points.

For the supporters of no admin boundaries in OSM, build the case on the
mailing lists instead of just saying there is a growing support for no
boundaries. In some parts of the US there is a growing support that climate
change is a hoax. That doesn't make it true. Build a case for removing
admin boundaries (and please include landuse.)

Ideally in the future we can have a fuzzy boundary. But until then I think
what I proposed is an acceptable solution.

Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Bryce Nesbitt]

On Mon, Mar 23, 2015 at 10:39 AM, Clifford Snow cliff...@snowandsnow.us
wrote:

 Except when it reports you are in a different neighborhood than you
 actually are.


A point feature does not imply a radius.

A governmental defined neighborhood boundary is totally mappable at the
right admin level, and you would
not need point features in such a case.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

tl;dr: I'm against a blanket rule when it comes to administrative 
boundaries. They're really nuanced, and so should we.


On 2015-03-22 04:32, Serge Wroclawski wrote:

Imagine if Bob and Alice conflict on where a neighborhood boundary is
inside OSM. The issue escalates to an edit war and the DWG is called
in to resolve the conflict. Let's say that Frank is our DWG member.
How is Frank supposed to resolve the conflict between Alice and Bob?
Often neighborhoods don't have administrative recognition, or
administrative recognition is not in alignment with the people. I
imagine this would be especially an issue with neighborhoods where
lots of the under-represented populations live.


This is an important consideration. As I mentioned in a footnote 
earlier, even a city with strong neighborhood organization can have 
boundary disputes. However, the problem exists for administrative 
boundaries in general, all the way up to admin_level=2 boundaries that 
cut right across ethnic fault lines.


My point was that we should map neighborhood boundaries in cities where 
doing so requires little editorial judgment, thanks to signage, 
distinctive lamp posts, etc. And we are quite clear (via the tag value 
administrative) that this isn't the only way by which a community can 
be delimited. As numerous threads have pointed out, the USPS has very 
different ideas of location (ZIP codes), but that's OK.


When it comes to all our discussions around *administrative* boundaries, 
I like this two-point test as a rule of thumb:


1. Are people or property governed differently on one side versus the other?

2. Is this distinction observable on the ground?

Municipalities generally pass both points. Congressional districts pass 
#1 but not #2. CDPs generally fail both. School districts can be 
observed, but not with the granularity required for mapping a boundary. 
City neighborhoods may pass one, both, or neither. Maybe all the locals 
you interview can agree on the name of a neighborhood but not its shape 
-- in which case it should be nothing more than a POI.


Which brings me to Serge's other point:


First, there are a growing number of people who believe that
administrative data is very useful, but breaks OSM's ground
observable rule. That is, someone who is present on the ground should
be able to observe the data in OSM. It's usually not possible to do
that with administrative boundaries.


SteveA has responded more forcefully on this point, and so have I in the 
past. [1] Fortunately, Alice and Bob's disagreement sounds pretty 
clear-cut. If the city didn't go through the trouble of demarcating any 
part of the boundary in some way, perhaps the general public shouldn't 
expect OSM to reproduce their two neighborhoods' boundaries at all. But 
I see no reason why such a decision would impact boundaries with very 
different characteristics.


-*-*-*-

Serge's focus on verifiability relates to a boundary I've spent a lot of 
time on lately, so I'm going to go way over my word limit.


Last month, I reminded this list that state borders along the Ohio River 
actually follow the river's historical northern bank, not its 
present-day thalweg or centerline. [2] Even if you send a diver into the 
river, there isn't always going to be a natural feature to verify OSM 
data against. We have a few options:


1. Try to be as accurate as possible by tracing USGS topo maps. Treat 
these borders as a practical exception to the on-the-ground rule. Use 
the source tag rigorously.


2a. Conflate the state borders with the current thalweg. We'd give Ohio 
and Indiana various islands and dams that actually belong to Kentucky 
and West Virginia, ignoring the Supreme Court ruling. We'd be putting 
intentionally inaccurate data into OSM.


2b. Conflate the state borders with the current northern bank, siding 
with Kentucky and again ignoring the Supreme Court ruling. We'd give the 
entire river to Kentucky and West Virginia, including riverboat casinos 
that keep to the Indiana side but are illegal in Kentucky.


3. Omit the river boundaries but leave the rest of the state lines 
intact. This approach introduces technical problems like broken 
multipolygon relations and just confuses people. Where does West 
Virginia end?


4. Omit the entire boundaries of states that border the Ohio River. 
It'll look like a mistake, so people will helpfully and sloppily add the 
boundaries back in.


5. Omit all state lines, everywhere, throwing away lots and lots of 
fixup work done with care by volunteer mappers. And all because Kentucky 
wanted the whole river.


Everyone agrees the river is the boundary, just not what the river 
means. In this case, I say we hold our noses and go with #1 as the most 
accurate, least disruptive approach. [3]


[1] 
https://lists.openstreetmap.org/pipermail/talk-us/2013-January/010162.html
[2] 
https://lists.openstreetmap.org/pipermail/talk-us/2015-February/014307.html

[3] 

[OSM-talk-be] boundaries of deelgemeenten

[Marc Gemis]

I found this site of the UGent: http://www.hisgis.be/nl/start_nl.htm

unfortunately, the cannot provide the shape files due to license
restrictions. (I've contacted them)

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

Re: [OSM-talk] Admin boundaries - data consumers

[Jean-Marc Liotier]

On 11/10/2013 01:45 PM, Arun Ganesh wrote:
 In India the law requires that the external boundaries of the country
 include parts of Kashmir that is now under control of foreign
 countries. This regularly causes issues when OSM is demoed publicly at
 institutes or to government officials. Also the startup community is
 apprehensive of using openstreetmap because of this issue.

 In this case, its the law that is broken, but adapting OSM to be able
 to handle such political challenges is more feasible than fixing the law.

Easy: take everything from OSM but the borders and supply your own
favourite borders from a separate source with a nice big Indian
government stamp on it. Render to taste.


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

Re: [OSM-talk] Admin boundaries - data consumers

[Arun Ganesh]

 Easy: take everything from OSM but the borders and supply your own
 favourite borders from a separate source with a nice big Indian
 government stamp on it. Render to taste.


Having new tile layer on osm.org that does not have any international
boundaries (or hiding those that are disputed)  would solve the issue much
more easily rather than requiring everyone affected to setup their own
tileservers. This issue affects half the global internet population and is
a definite barrier against the global adoption of this project.

-- 
 Arun Ganesh
(planemad) http://en.wikipedia.org/wiki/User:Planemad
 http://j.mp/ArunGanesh
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Jason Remillard]

Hi

Does India have a local osm chapter? If yes, this would be a perfect place
to host the tiles. Many local chapters host tile servers.

Thanks
Jason

On Monday, November 11, 2013, Arun Ganesh wrote:


 Easy: take everything from OSM but the borders and supply your own
 favourite borders from a separate source with a nice big Indian
 government stamp on it. Render to taste.


 Having new tile layer on osm.org that does not have any international
 boundaries (or hiding those that are disputed)  would solve the issue much
 more easily rather than requiring everyone affected to setup their own
 tileservers. This issue affects half the global internet population and is
 a definite barrier against the global adoption of this project.

 --
  Arun Ganesh
 (planemad) http://en.wikipedia.org/wiki/User:Planemad
  http://j.mp/ArunGanesh

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

Re: [OSM-talk] Admin boundaries - data consumers

[Christian Quest]

OSM is a global and worldwide project and cannot deal with all local issues.

For example, in France some names/routes are trade marks and for this
reason should not be visible on maps unless authorized.
So what ? Should we remove these routes from the osm.org default rendering
? Create one more rendering just to deal with this ?

OSM is a data project, and these data allow to make maps, not one single
map, but maps.

If the default map does not fit one need, just use the data and the tools
to make your own. That's what we did with these trademarked routes... they
are hidden on OSM-FR tiles.

Adoption of the project is also to reuse the data, not the basic services
provided by osm.org servers.


2013/11/11 Arun Ganesh arun.plane...@gmail.com


 Easy: take everything from OSM but the borders and supply your own
 favourite borders from a separate source with a nice big Indian
 government stamp on it. Render to taste.


 Having new tile layer on osm.org that does not have any international
 boundaries (or hiding those that are disputed)  would solve the issue much
 more easily rather than requiring everyone affected to setup their own
 tileservers. This issue affects half the global internet population and is
 a definite barrier against the global adoption of this project.



-- 
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Martin Koppenhoefer]

2013/11/11 Christian Quest cqu...@openstreetmap.fr

 OSM is a data project, and these data allow to make maps, not one single
 map, but maps.

 If the default map does not fit one need, just use the data and the tools
 to make your own. That's what we did with these trademarked routes... they
 are hidden on OSM-FR tiles.



I think it is an interesting proposal to put an alternative mapstyle on
osm.org without the admin boundaries.

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Jean-Marc Liotier]

On 11/11/2013 06:02 PM, Martin Koppenhoefer wrote:
 I think it is an interesting proposal to put an alternative mapstyle
 on osm.org http://osm.org without the admin boundaries.

While a map without borders is quite a powerful philosophical statement,
is it really part of Openstreetmap's core role ? As Christian said, let
users answer their political and artistic urges through using the
Openstreetmap data - let a thousand renders bloom ! A new map style as a
core service would be yet another nitpicking topic, mired in mailing
list discussions... Openstreetmap's strength is that only the data
requires consensus - each user has the freedom to produce his ideal
rendering of the data without having to ask anyone's permission... Let
them take advantage of it !

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

Re: [OSM-talk] Admin boundaries - data consumers

[nicholas . g . lawrence]

 On 11/11/2013 06:02 PM, Martin Koppenhoefer wrote:
 I think it is an interesting proposal to put an alternative mapstyle on 
 osm.org without the admin boundaries.
 
 While a map without borders is quite a powerful philosophical 
 statement, is it really part of Openstreetmap's core role ? As 
 Christian said, let users answer their political and artistic urges 
 through using the Openstreetmap data - let a thousand renders bloom 
 ! A new map style as a core service would be yet another nitpicking 
 topic, mired in mailing list discussions... Openstreetmap's strength
 is that only the data requires consensus - each user has the freedom
 to produce his ideal rendering of the data without having to ask 
 anyone's permission... Let them take advantage of it !

So, someone could build a renderer for openbordermap?

nick
***
WARNING: This email (including any attachments) may contain legally
privileged, confidential or private information and may be protected by
copyright. You may only use it if you are the person(s) it was
intended to be sent to and if you use it in an authorised way. No one
is allowed to use, review, alter, transmit, disclose, distribute, print
or copy this email without appropriate authority.

If this email was not intended for you and was sent to you by mistake,
please telephone or email me immediately, destroy any hardcopies of
this email and delete it and any copies of it from your computer
system. Any right which the sender may have under copyright law, and 
any legal privilege and confidentiality attached to this email is not
waived or destroyed by that mistake.

It is your responsibility to ensure that this email does not contain 
and is not affected by computer viruses, defects or interference by 
third parties or replication problems (including incompatibility with
your computer system).

Opinions contained in this email do not necessarily reflect the
opinions of the Department of Transport and Main Roads,
or endorsed organisations utilising the same infrastructure.
***



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

Re: [OSM-talk] Admin boundaries - data consumers

[Florian Lohoff]

On Sat, Nov 09, 2013 at 05:59:19PM +, Craig Wallace wrote:
 Note MySociety do not use boundaries from OSM for the UK for their
 projects. Instead they just use boundaries from OS OpenData.
 I think this is an example of where a separate database makes sense.
 ie with the complete, up to date OS OpenData boundaries, in a format
 compatible with OSM.
 
 Yes, some of the OS OpenData boundaries have been added to OSM. But
 they are very incomplete/inconsistent, and often accidentally edited
 or broken etc. And probably out of date if the official boundaries
 have changed anywhere. So generally not as useful or reliable as
 just using the OS OpenData.

This will not be fixed by seperating out the boundarys.

If MySociety is interested in up to date, complete and non broken 
boundarys it could sponsor a simple monitoring tool for boundaries.
As soon as there is a hint something is broken there are hundrets
of mappers interested in fixing.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Arun Ganesh]

 In my opinion this is an example where OSM data is broken and should be
 fixed.

 Andrew


 In India the law requires that the external boundaries of the country
include parts of Kashmir that is now under control of foreign countries.
This regularly causes issues when OSM is demoed publicly at institutes or
to government officials. Also the startup community is apprehensive of
using openstreetmap because of this issue.

In this case, its the law that is broken, but adapting OSM to be able to
handle such political challenges is more feasible than fixing the law.

Google, Bing and other map providers display a different set of boundaries
based on the laws of the user's country. But for OSM, it would probably a
very simple solution if we have a lowzoom tileset which don't have any
international borders. Would that be a good idea?

-- 
 Arun Ganesh
(planemad) http://en.wikipedia.org/wiki/User:Planemad
 http://j.mp/ArunGanesh
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Peter Wendorff]

Am 10.11.2013 13:45, schrieb Arun Ganesh:
 In my opinion this is an example where OSM data is broken and should be
 fixed.

 Andrew


  In India the law requires that the external boundaries of the country
 include parts of Kashmir that is now under control of foreign countries.
 This regularly causes issues when OSM is demoed publicly at institutes or
 to government officials. Also the startup community is apprehensive of
 using openstreetmap because of this issue.
 
 In this case, its the law that is broken, but adapting OSM to be able to
 handle such political challenges is more feasible than fixing the law.
 
 Google, Bing and other map providers display a different set of boundaries
 based on the laws of the user's country. But for OSM, it would probably a
 very simple solution if we have a lowzoom tileset which don't have any
 international borders. Would that be a good idea?
If you need wrong (according to the facts) data for legal reasons, then
patch the osm dataset with the official boundaries here and render
tiles from it.
Rendering tiles isn't that difficult, at least if we're talking about
demoing and so on.
Use osm, replace the indian boundary by the legal version and render
tiles from it. If you still keep the original stylesheet you would need
only to replace the affected tiles there by your own (if it's feasible
for the demo to use the original osm tiles - according to the tile usage
policy).

I don't think this is a problem with OSM in particular, but with every
correct dataset not originating in india.

regards
Peter

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

[OSM-talk] Admin boundaries - data consumers

[Rob Nickerson]

Hi All,

A few days ago there was a thread about the pros/cons of moving admin
boundaries to a new database. I'm not going to give my opinion on this as
the thread has now fizzled out, but I will suggest that decisions like this
should involve as many of our end data users as possible (we have moved
beyond a small isolated project).

One such user is mySoicety. Check out the video of their MapIt Global talk
at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use boundaries from
OSM.

Perhaps some way of tracking our data consumers would be useful. Or maybe
we need a way for them to say which tags they are interested in so that
they can receive mail just about these.

Regards,
Rob
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Jochen Topf]

On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote:
 A few days ago there was a thread about the pros/cons of moving admin
 boundaries to a new database. I'm not going to give my opinion on this as
 the thread has now fizzled out, but I will suggest that decisions like this
 should involve as many of our end data users as possible (we have moved
 beyond a small isolated project).
 
 One such user is mySoicety. Check out the video of their MapIt Global talk
 at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use boundaries from
 OSM.
 
 Perhaps some way of tracking our data consumers would be useful. Or maybe
 we need a way for them to say which tags they are interested in so that
 they can receive mail just about these.

That's the wrong way around. If you are using OSM data it is your job to keep
abreast of developments in OSM. A volunteer project like OSM can't keep track
of all their customers the way a commercial company might. That's not to
say that we should change things willy-nilly, we should announce changes
beforehand etc. But we do that on our mailing lists etc. And yes, that puts
a lot of burden on the users of OSM data, but they get it for free, so there.
(Of course there are companies who will do this job for you, ie follow OSM
development while maintaining stable data formats etc. to their customers.)

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] Admin boundaries - data consumers

[Colin Smale]

 

That does come across as a little arrogant, Jochen. The mappers and the
data consumers need each other; neither can flourish without the other.
A symbiotic model would be more accurate. As you say, we shouldn't
change things willy-nilly, but to say bluntly it's your problem to all
data consumers and to express such a dismissive attitude towards their
feedback is misrepresenting the relationship somewhat. 

Colin 

On 2013-11-09 18:25, Jochen Topf wrote: 

 On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote:
 
 A few days ago there was a thread about the pros/cons of moving admin 
 boundaries to a new database. I'm not going to give my opinion on this as 
 the thread has now fizzled out, but I will suggest that decisions like this 
 should involve as many of our end data users as possible (we have moved 
 beyond a small isolated project). One such user is mySoicety. Check out the 
 video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ [1] 
 to see how they use boundaries from OSM. Perhaps some way of tracking our 
 data consumers would be useful. Or maybe we need a way for them to say which 
 tags they are interested in so that they can receive mail just about these.
 
 That's the wrong way around. If you are using OSM data it is your job to keep
 abreast of developments in OSM. A volunteer project like OSM can't keep track
 of all their customers the way a commercial company might. That's not to
 say that we should change things willy-nilly, we should announce changes
 beforehand etc. But we do that on our mailing lists etc. And yes, that puts
 a lot of burden on the users of OSM data, but they get it for free, so there.
 (Of course there are companies who will do this job for you, ie follow OSM
 development while maintaining stable data formats etc. to their customers.)
 
 Jochen
 

Links:
--
[1] http://lanyrd.com/2013/sotm/scpkhg/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Craig Wallace]

On 2013-11-09 15:25, Rob Nickerson wrote:

Hi All,

A few days ago there was a thread about the pros/cons of moving admin
boundaries to a new database. I'm not going to give my opinion on this
as the thread has now fizzled out, but I will suggest that decisions
like this should involve as many of our end data users as possible (we
have moved beyond a small isolated project).

One such user is mySoicety. Check out the video of their MapIt Global
talk at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use
boundaries from OSM.


Note MySociety do not use boundaries from OSM for the UK for their 
projects. Instead they just use boundaries from OS OpenData.
I think this is an example of where a separate database makes sense. ie 
with the complete, up to date OS OpenData boundaries, in a format 
compatible with OSM.


Yes, some of the OS OpenData boundaries have been added to OSM. But they 
are very incomplete/inconsistent, and often accidentally edited or 
broken etc. And probably out of date if the official boundaries have 
changed anywhere. So generally not as useful or reliable as just using 
the OS OpenData.


Craig

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

Re: [OSM-talk] Admin boundaries - data consumers

[Matthijs Melissen]

On Nov 9, 2013 5:39 PM, Jochen Topf joc...@remote.org wrote;
 On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote:
  Perhaps some way of tracking our data consumers would be useful. Or
maybe
  we need a way for them to say which tags they are interested in so that
  they can receive mail just about these.

 That's the wrong way around. If you are using OSM data it is your job to
keep
 abreast of developments in OSM. A volunteer project like OSM can't keep
track
 of all their customers the way a commercial company might. That's not to
 say that we should change things willy-nilly, we should announce changes
 beforehand etc. But we do that on our mailing lists etc. And yes, that
puts
 a lot of burden on the users of OSM data, but they get it for free, so
there.

At the moment it is indeed not that easy for data consumers to keep track
of changes. The tagging mailing list had quite high traffic, and most posts
there are not directly relevant for data consumers.

I have been thinking about how we can improve this situation. Would it be
an idea to create a separate mailing list that just serves to announce
changes in the tagging scheme? That way we can separate the discussion on
creating tagging schemes (which data consumers can ignore if they wish)
from the announcements of new schemes.

Typically changes correspond to accepted proposals on the tagging mailing
list. We could add to the procedure of proposing tags that the proposer
should make an announcement to this list when hits proposal is accepted.

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

Re: [OSM-talk] Admin boundaries - data consumers

[Jochen Topf]

I am sorry if I came across as arrogant or dismissive. This is absolutely not
my intention. Actually I think we are in violent agreement here, mappers and
data consumers must talk and help each other. And where we do that is on our
mailing lists, forums, etc. What I was arguing against is somehow feeling
responsible for data users who take our data, never talk to us and then think
it is our job to tell them when something changes. That is how I understood
Rob's argument and that isn't something I feel we have to do. If, to keep with
Rob's example, MySociety wants to know about boundary tagging changes in OSM,
they can get this info by participating in the OSM community and I'd welcome
their input as a user of the data. But they have to be active themselves in at
least a small way, it is not our job to somehow keep track of what they are
using from OSM and tell them if something changes that they would want to know
about.

Jochen

On Sat, Nov 09, 2013 at 06:55:53PM +0100, Colin Smale wrote:
 Date: Sat, 09 Nov 2013 18:55:53 +0100
 From: Colin Smale colin.sm...@xs4all.nl
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] Admin boundaries - data consumers
 
  
 
 That does come across as a little arrogant, Jochen. The mappers and the
 data consumers need each other; neither can flourish without the other.
 A symbiotic model would be more accurate. As you say, we shouldn't
 change things willy-nilly, but to say bluntly it's your problem to all
 data consumers and to express such a dismissive attitude towards their
 feedback is misrepresenting the relationship somewhat. 
 
 Colin 
 
 On 2013-11-09 18:25, Jochen Topf wrote: 
 
  On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote:
  
  A few days ago there was a thread about the pros/cons of moving admin 
  boundaries to a new database. I'm not going to give my opinion on this as 
  the thread has now fizzled out, but I will suggest that decisions like 
  this should involve as many of our end data users as possible (we have 
  moved beyond a small isolated project). One such user is mySoicety. Check 
  out the video of their MapIt Global talk at 
  http://lanyrd.com/2013/sotm/scpkhg/ [1] to see how they use boundaries 
  from OSM. Perhaps some way of tracking our data consumers would be useful. 
  Or maybe we need a way for them to say which tags they are interested in 
  so that they can receive mail just about these.
  
  That's the wrong way around. If you are using OSM data it is your job to 
  keep
  abreast of developments in OSM. A volunteer project like OSM can't keep 
  track
  of all their customers the way a commercial company might. That's not to
  say that we should change things willy-nilly, we should announce changes
  beforehand etc. But we do that on our mailing lists etc. And yes, that puts
  a lot of burden on the users of OSM data, but they get it for free, so 
  there.
  (Of course there are companies who will do this job for you, ie follow OSM
  development while maintaining stable data formats etc. to their customers.)
  
  Jochen
  
 
 Links:
 --
 [1] http://lanyrd.com/2013/sotm/scpkhg/

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


-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] Admin boundaries - data consumers

[Jochen Topf]

On Sat, Nov 09, 2013 at 07:28:16PM +, Matthijs Melissen wrote:
 On Nov 9, 2013 5:39 PM, Jochen Topf joc...@remote.org wrote;
  On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote:
   Perhaps some way of tracking our data consumers would be useful. Or
 maybe
   we need a way for them to say which tags they are interested in so that
   they can receive mail just about these.
 
  That's the wrong way around. If you are using OSM data it is your job to
 keep
  abreast of developments in OSM. A volunteer project like OSM can't keep
 track
  of all their customers the way a commercial company might. That's not to
  say that we should change things willy-nilly, we should announce changes
  beforehand etc. But we do that on our mailing lists etc. And yes, that
 puts
  a lot of burden on the users of OSM data, but they get it for free, so
 there.
 
 At the moment it is indeed not that easy for data consumers to keep track
 of changes. The tagging mailing list had quite high traffic, and most posts
 there are not directly relevant for data consumers.
 
 I have been thinking about how we can improve this situation. Would it be
 an idea to create a separate mailing list that just serves to announce
 changes in the tagging scheme? That way we can separate the discussion on
 creating tagging schemes (which data consumers can ignore if they wish)
 from the announcements of new schemes.
 
 Typically changes correspond to accepted proposals on the tagging mailing
 list. We could add to the procedure of proposing tags that the proposer
 should make an announcement to this list when hits proposal is accepted.

Unfortunately the tagging discussions and voting doesn't actually matter that
much. It is not important what some people think or have agreed on what tags
should or should not be used in what situations. What is important to data
users is how the tags are *actually* used in the database.  And I don't see
that much correlation between actual use and this proposal procedure. A
change in an editor configuration might have more impact than a vote in the
proposal process.

This situation isn't great, but it is what we have. Data users have to
familiarize themselves with what's there. They have to read wiki pages, look at
taginfo, look at discussions on mailing lists and they have to try out
different interpretations of the data and find out what works for them. There
is no shortcut to this process. There are many ways of making this easier,
one is writing better wiki documentation, one is finding better ways of putting
these information into taginfo. But highlighting results from a proposal
process that doesn't matter all that much, isn't one of them.

(btw I would welcome some university research on whether my assertions above
are actually true. I'd love to have some data that tells us how tagging in the
actual database is driven by tagging proposals, or editor choices, or people
just inventing tags they like, or local fashions etc.)

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] Admin boundaries - data consumers

[Rob Nickerson]

Jochen Topf said:

I am sorry if I came across as arrogant or dismissive. This is absolutely
not
my intention.

No offence taken. As you say, we are in agreement here, mappers and data
consumers must talk and help each other.


What I was arguing against is somehow feeling
responsible for data users who take our data, never talk to us and then
think
it is our job to tell them when something changes. That is how I understood
Rob's argument


Perhaps I misled you as I agree 100% that the relationship has to be two
way. I'm just wondering aloud how we can improve out side of that
conversation / relationship. As we all know the mailing lists can be quite
unfriendly to external parties. It's an interesting question as we need to
balance providing data consumers with advanced notice of big changes and
still be able to act quickly. My experience with developing tagging schemas
is that it helps to slow the process down, giving everyone time to consider
the tag and provide comments. I would have liked more involvement from
someone who actually uses the data (in this case a Routing service
provider) but as you say they have to be willing to join the conversation
too. We cannot slow things down too much :-)

Best,
Rob
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Admin boundaries - data consumers

[Andrew Errington]

On Sun, 10 Nov 2013 02:59:19 Craig Wallace wrote:
 Note MySociety do not use boundaries from OSM for the UK for their
 projects. Instead they just use boundaries from OS OpenData.
 I think this is an example of where a separate database makes sense. ie
 with the complete, up to date OS OpenData boundaries, in a format
 compatible with OSM.

In my opinion this is an example where OSM data is broken and should be fixed.

Andrew

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

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

I have finally found the way. I leave some examples here:

As JSON:
http://www.wikidata.org/w/api.php?action=wbgetentitiesids=Q5720languages=enformat=json
As XML:
http://www.wikidata.org/w/api.php?action=wbgetentitiesids=Q5720languages=enformat=xml

Using title:
http://www.wikidata.org/w/api.php?action=wbgetentitiessites=enwikititles=Valencian%20Communitylanguages=enformat=xml

Regards,

César


2013/10/4 Eugene Alvin Villar sea...@gmail.com

 On Fri, Oct 4, 2013 at 1:35 AM, César Martínez Izquierdo 
 cesar@gmail.com wrote:

 Thanks Eugene, that looks really promising.
 I've seen there is an API to query Wikidata (results can be list of
 Wikidata item IDs encoded as JSON), but I don't see the way to get the item
 itself as JSON (or any other parseable format). Is it on the way?


 Unfortunately, I am not up-to-par with the API side of Wikidata. I assume
 that every bit of data on Wikidata can or will be accessible through APIs.
 Otherwise, it would limit the usefulness of Wikidata if we resort to
 scraping the HTML page.





-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-SIA: http://sia.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

 Am 02/ott/2013 um 23:52 schrieb Christian Quest cqu...@openstreetmap.fr:
 
 UK level 4 is on the maritime borders (island culture ?) where most other 
 European countries stop on the coastline... tagging bio-diversity is not 
 helpful !


well, maybe this is how things are correct? years ago I stumbled upon Liberia 
having a 200NM maritime border. Checking with other sources it turned out that 
they indeed claim this area. Looking now at the osm map someone has 
normalized the coastline leaving them the same maritime border than the rest, 
and it looks better but I'm not sure it also is more correct.

The world is divers and the map should represent how things are, even if this 
seems more chaotic than nicely structured.

cheers,
Martin


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

Re: [OSM-talk] Administrative boundaries export

[Christian Quest]

Well, I think I fully understand all the diversity, but when you want the
shape of UK or Liberia, I presume most people expect the land, not the
maritime boundaries claimed ones or whatever.

This does not prevent to have 2 boundary relations, one for land boundary
and one including maritime ones (that's the case for France for example +
one including overseas land), but make sure the tagging is homogeneous
worldwide as far as possible to allow easy reuse of data.

I've been asked too about all maritime boundaries of the world... I tried
to extract that but it was too inconsistent to be useable.



2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com



  Am 02/ott/2013 um 23:52 schrieb Christian Quest cqu...@openstreetmap.fr
 :
 
  UK level 4 is on the maritime borders (island culture ?) where most
 other European countries stop on the coastline... tagging bio-diversity is
 not helpful !


 well, maybe this is how things are correct? years ago I stumbled upon
 Liberia having a 200NM maritime border. Checking with other sources it
 turned out that they indeed claim this area. Looking now at the osm map
 someone has normalized the coastline leaving them the same maritime
 border than the rest, and it looks better but I'm not sure it also is
 more correct.

 The world is divers and the map should represent how things are, even if
 this seems more chaotic than nicely structured.

 cheers,
 Martin




-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

Thanks for all the advises and suggestion. I agree that in order to achieve
this, at least 2 tables/trees/dbs have to be maintained:

1 - The relationship of each admin_boundary on a certain level with its
parent (and the opposite) and whether this same boundaries applies for
other admin_boundaries (as suggested for some areas of Germany)
2 - For each country, how to distinguish the land mass from territorial
waters. I am more interested on mapping the land mass, but the territorial
waters could be also generated if we have this distinction.

Regarding 1, I think it would be reasonable to try to codify it within OSM
(for instance using is_in tag), but I think the tagging scheme should be
further developed to correctly capture all the information we need, so I
will generate an external table/database instead. Probably, a table per
admin_level containing relation-id, ISO 3166 code would be enough (but I
have to study what should be used for deeper subdivision levels), as it
will contain the father-children relationships and also would solve the
problem with a boundary being the same for different admin_levels. The
algorithm could check against OSM data for code and for relation-id when
missing, and report any added or removed boundaries compared with previous
version.

Regarding 2, for the long term I thing separate relationships should be
present in OSM for land mass and territorial waters (this also involves
clarifying the tagging scheme), but for the moment I will try to manage
with existing tags.

I assume it will not be a small task, so I will try to be pragmatic and
start exporting what can be exported using a straightforward way and then
refining the approach little by little. Probably, in order to refine these
approaches it would be helpful to have some viewer similar to the one on
openstreetmap.fr (to easily see what should be corrected on OSM data or on
the extraction algorithms), but for the moment this is outside of my plans.

I expect results on the scale of months/years rather than days/weeks
(according to my planned dedication), but I will keep you informed when I
get some news.

Eugene, I am also interested on your proposal to store on Wikidata a
table/database similar to the one described on 1, so any further details on
available infrastructure, technologies in use, work already done, etc are
welcome.

Cheers,

César Martínez Izquierdo



2013/10/3 Eugene Alvin Villar sea...@gmail.com

 On Thu, Oct 3, 2013 at 6:52 AM, Christian Quest 
 cqu...@openstreetmap.frwrote:

 UK level 4 is on the maritime borders (island culture ?) where most other
 European countries stop on the coastline... tagging bio-diversity is not
 helpful !


 This is actually another point to consider when extracting admin
 boundaries from OSM data.

 My personal view is that the admin boundary marks the boundary where the
 administrative entity exercises jurisdiction. Under UNCLOS, nations are
 allowed to exercise full sovereignty over internal waters (which includes
 water seaward of the coastline but within the baselines) and almost full
 sovereignty (foreign ships are allowed innocent passage) for territorial
 waters (up to 12 nautical miles from the baselines). So I think that using
 the maritime boundaries as the admin_level=2 boundary is not incorrect and
 this is reflected in OSM.

 Use of maritime boundaries for admin_level=3 and higher (such as with UK)
 depends on how the particular nation interprets its internal
 maritime/fisheries laws. In my country, we have municipal waters which
 can be up to 15 kilometers from the shoreline and that's where
 municipalities can exercise jurisdiction.

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




-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-SIA: http://sia.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

2013/10/3 César Martínez Izquierdo cesar@gmail.com

 2 - For each country, how to distinguish the land mass from territorial
 waters. I am more interested on mapping the land mass, but the territorial
 waters could be also generated if we have this distinction.



no, the landmass is the land inside the territorial waters, but the
territorial waters are not the extension of the coastline by 12seamiles but
the extension of the baseline. We generally do not have the baselines in
OSM as far as I am aware of.

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

2013/10/3 Christian Quest cqu...@openstreetmap.fr

 Well, I think I fully understand all the diversity, but when you want the
 shape of UK or Liberia, I presume most people expect the land, not the
 maritime boundaries claimed ones or whatever.



yes, but you don't need a special relation for this, you only have to find
out the coastlines inside the territory (and where they cross the national
borders so you can find out the land borders to other countries).




 This does not prevent to have 2 boundary relations, one for land boundary
 and one including maritime ones



you don't need them, and you will put unneccessary heavy load on the db
creating a relation with all coastlines and the land side borders in it (as
the coastlines are much more detailed than the baseline). In the end,
that's the reason we do coastlines with shapefiles and not with huge
polygons. We used to have a landmass relation for Italy as well, because
some well meaning mappers have created them for us, but it was continuously
broken and augmented the complexity for coastline edits with an
unneccessary complication. It grew in short time to 928 versions, so after
a discussion on talk-it, and with nobody needing it, we decided to delete
it some weeks ago: http://www.openstreetmap.org/browse/relation/957374



 (that's the case for France for example + one including overseas land),
 but make sure the tagging is homogeneous worldwide as far as possible to
 allow easy reuse of data.



My suggestion would be to delete the French landmass relation as well for
homogenisation ;-)

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

Hi Frederik, regarding software, I am already familiar with Mapit scripts
code, which are able to extract admin boundary polygons for each level (it
is not creating relationships though). How do you see Nominatim or
Osmium/osmjs better for the purpose? Reading osmjs documentation, I see it
could be used to build a similar script to mapit one (which uses a local
instance of OSM3S api). Do you think it would be faster?

I envisage 2 possible approaches:
- using one of these tools to do a first export, which should be later
processed by a separate script in order to make sense on the
particularities of each country.
- creating an export script from scratch (similar to or based on Mapit
scripts) that select the right relations and tags for each country. It
should be faster but probably more costly to implement

I will probably try the first option, but I expect that any of them would
be costly to maintain if there are frequent changes of the tagging scheme
for each country. (But nobody said it would be an easy task :-)

Cheers,

César

2013/10/2 Frederik Ramm frede...@remote.org

 Hi,

 On 02.10.2013 18:23, César Martínez Izquierdo wrote:
  I plan to create and make easily available a world-wide administrative
  layer based on OSM data, ideally including existing administrative codes
  (ISO, NUTS in Europe, etc) for each level and producing regular updates
  (for instance once a year).

 This is something I have been thinking about for a long time (but never
 written any usable code).

 Nominatim is probably a good starting point - a better one than MapIt I
 should think.

 If you're only after extracting certain relation polygons then you could
 as well use osmjs (part of Osmium) and have it generate shape files for
 you, or adapt the shapefile/ogr export samples in Osmium; this will not
 yet give you a hierarchy, only individual boundaries, and you have to
 find out the hierarchy yourself.

 Finding out the hierarchy is going to be tricky. Nominatim does go to
 some lengths to do that already. It sounds easy (find all polygons with
 an admin level smaller than X where this polygon I'm looking at lies
 in). But in reality you will encounter at least:

 * missing polygons on all levels - sometimes simply not mapped,
 sometimes missing by design, e.g. Germany has some areas where admin
 levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
 a map of all admin_level 8 areas in Germany and you have lots of holes
 in them

 * broken polygons on all levels; brokenness changes by the day, i.e.
 what is working today may be broken tomorrow and vice versa

 * occasionally (e.g. Japan) linear regional boundaries that simply go
 from coast to coast without including the coastline

 * occasionally (e.g. Chile) a regional boundary that is not a
 multipolygon relation but instead a grouping of smaller regional entities

 * sometimes small geometric inaccuracies mean that e.g. a state boundary
 fails the is-in test for the country boundary because there's just a
 little square metre somewhere that is mapped as belonging to the state
 but not the country

 * overlapping admin polygons of the same admin level

 I think that ate the very least you need to run the evaluation regularly
 and compare: Do I have new polygons this week - have others vanished,
 and if so, is that because they were explicitly deleted/replaced, or
 were they just accidentally broken and I should continue to use last
 week's?

 What we would really need though, is something much bigger: A separate
 database of admin hierarchies, where people could - in a crowdsourced
 manner - record things like:

 There is an adminlevel 2 entities called Germany
 It is divided into 16 exclusive adminlevel 4 entities with the
 following names: ...
 These 16 entities cover the area of Germany completely (no holes or sea
 areas that would be outside of one of the entities)
 The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel
 6 entities...

 and so on. A tree of arbitrary size where people can add and edit at will.

 Now you will say but this tree could be generated from OpenStreetMap,
 and I grant that one could attempt to build such a tree but it will
 always be faulty and reflect the current brokenness of geometries in
 OSM. One could *start* with an OSM-generated tree, but after that, the
 tree must be kept separate. People should be able to add stuff to the
 tree even when it is not in OpenStreetMap - there should be an
 adminlevel 8 boundary called so-and-so. A regularly-running process
 would then compare the tree to OpenStreetMap, and generate error reports
 that can be presented visually:

 The tree says that there should be a region called X in Germany but OSM
 doesn't have one.

 There is an area here that is not covered by any adminlevel 4 area but
 the tree says that taken together the adminlevel 4 areas must cover all
 of the country.

 The tree claims there should be a region called X but in OSM there's
 only a region 

Re: [OSM-talk] Administrative boundaries export

[Frederik Ramm]

Hi,

On 10/03/13 12:32, César Martínez Izquierdo wrote:
 Hi Frederik, regarding software, I am already familiar with Mapit
 scripts code, which are able to extract admin boundary polygons for each
 level (it is not creating relationships though). How do you see
 Nominatim or Osmium/osmjs better for the purpose? Reading osmjs
 documentation, I see it could be used to build a similar script to mapit
 one (which uses a local instance of OSM3S api). Do you think it would be
 faster?

I would think so. The Mapit stack is very convoluted - as far as I
remember, it first extracts stuff from a planet file with Osmosis, then
imports that into osm3s (aka overpass), then makes queries from there.
This is a very complicated way to do it - with an osmjs/osmium based
program you'd process the planet once and that's it (if using OGR output
like in the osmium_toogr example you can even generate KML directly),
and the time spend would very likely be much less than even the initial
Osmosis step of the Mapit stack. I'd assume it would take a couple hours
for a full export.

Of course if you're already familiar with the Mapit stack and it works
for you, that's fine too.

 - using one of these tools to do a first export, which should be later
 processed by a separate script in order to make sense on the
 particularities of each country.

Yes, I think that makes sense, however keep in mind that depending on
how you do the export, some things might already be broken at that
stage, and no chance for a program down the line to fix it. The export
process would probably have to be modified to export a collection of
broken things in addition to the working things, so that a script down
the line can then do something with the broken things.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

Re: [OSM-talk] Administrative boundaries export

[Sarah Hoffmann]

On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:
 Hi Frederik, regarding software, I am already familiar with Mapit scripts
 code, which are able to extract admin boundary polygons for each level (it
 is not creating relationships though). How do you see Nominatim or
 Osmium/osmjs better for the purpose? 

Nominatim already does a lot of the stuff you are planning to do. It 
creates geometries for admin boundaries from OSM data and puts them 
in a proper hierarchy. It is able to process updates and in the 
process makes sure that boundaries do not just disappear if somebody
breaks the relation. If you only process the data that interests you 
(boundary=administrative and place nodes) it is not even that 
resource-hungry.

It does have support for listing broken boundaries [1] and during the
last hack day Brian has written a proof-of-concept for browsing admin
hierarchies[2]. There is even a script to dump objects within a certain 
boundary[3] which could be easily extended to dump entire hierarchies.
All these functions should currently be used with care though. There are
known bugs and the output needs to be improved to make them really
usable.

Basically, most of the work to do would be on the output side, the 
heavy lifting of processing the data is already done. Well, apart 
from checking the OSM boundaries against reality. But I think wiki data 
is a good starting point for that.

 I will probably try the first option, but I expect that any of them would
 be costly to maintain if there are frequent changes of the tagging scheme
 for each country. (But nobody said it would be an easy task :-)

Making boundary tagging more visible will hopefully help to stablize
and unify the tagging schemas. The less country-specific exceptions
the better.

Sarah

[1] http://nominatim.osm.org/polygons
[2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985
(This is for demonstration only, please do not scrape. It will not
always give you the expected results anyways because there is a
known bug with parenting which still lingers in the DB.)
[3] https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php

 2013/10/2 Frederik Ramm frede...@remote.org
 
  Hi,
 
  On 02.10.2013 18:23, César Martínez Izquierdo wrote:
   I plan to create and make easily available a world-wide administrative
   layer based on OSM data, ideally including existing administrative codes
   (ISO, NUTS in Europe, etc) for each level and producing regular updates
   (for instance once a year).
 
  This is something I have been thinking about for a long time (but never
  written any usable code).
 
  Nominatim is probably a good starting point - a better one than MapIt I
  should think.
 
  If you're only after extracting certain relation polygons then you could
  as well use osmjs (part of Osmium) and have it generate shape files for
  you, or adapt the shapefile/ogr export samples in Osmium; this will not
  yet give you a hierarchy, only individual boundaries, and you have to
  find out the hierarchy yourself.
 
  Finding out the hierarchy is going to be tricky. Nominatim does go to
  some lengths to do that already. It sounds easy (find all polygons with
  an admin level smaller than X where this polygon I'm looking at lies
  in). But in reality you will encounter at least:
 
  * missing polygons on all levels - sometimes simply not mapped,
  sometimes missing by design, e.g. Germany has some areas where admin
  levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
  a map of all admin_level 8 areas in Germany and you have lots of holes
  in them
 
  * broken polygons on all levels; brokenness changes by the day, i.e.
  what is working today may be broken tomorrow and vice versa
 
  * occasionally (e.g. Japan) linear regional boundaries that simply go
  from coast to coast without including the coastline
 
  * occasionally (e.g. Chile) a regional boundary that is not a
  multipolygon relation but instead a grouping of smaller regional entities
 
  * sometimes small geometric inaccuracies mean that e.g. a state boundary
  fails the is-in test for the country boundary because there's just a
  little square metre somewhere that is mapped as belonging to the state
  but not the country
 
  * overlapping admin polygons of the same admin level
 
  I think that ate the very least you need to run the evaluation regularly
  and compare: Do I have new polygons this week - have others vanished,
  and if so, is that because they were explicitly deleted/replaced, or
  were they just accidentally broken and I should continue to use last
  week's?
 
  What we would really need though, is something much bigger: A separate
  database of admin hierarchies, where people could - in a crowdsourced
  manner - record things like:
 
  There is an adminlevel 2 entities called Germany
  It is divided into 16 exclusive adminlevel 4 entities with the
  following 

Re: [OSM-talk] Administrative boundaries export

[Paul Norman]

From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Sent: Thursday, October 03, 2013 3:20 AM
Subject: Re: [OSM-talk] Administrative boundaries export

 you don't need them, and you will put unneccessary heavy load on the db 
 creating a relation with all coastlines and the land side borders in it 
 (as the coastlines are much more detailed than the baseline). 

Expanding on this, there are some large boundary relations which have 
all the coastline for an admin_level region and have over 10 000 
members. These are frankly harmful and impossible to work with. 

When I redid the Alaska boundaries, I put them at 3 miles out I believe. 

Frankly, I find the idea of using the coastline as an admin boundary 
rather silly. This would mean that if you step out 1 foot into the 
water, you've left the state or country.


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

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

2013/10/3 Paul Norman penor...@mac.com


 Frankly, I find the idea of using the coastline as an admin boundary
 rather silly. This would mean that if you step out 1 foot into the
 water, you've left the state or country.



indeed it seems to be different: en.wikipedia.org/wiki/Territorial_waters
look at the internal waters in the diagram, those allow to reduce the
admin-ways a lot by simplifying and not using the coastline.

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Eugene Alvin Villar]

On Thu, Oct 3, 2013 at 9:18 PM, Martin Koppenhoefer
dieterdre...@gmail.comwrote:


 2013/10/3 Paul Norman penor...@mac.com


 Frankly, I find the idea of using the coastline as an admin boundary
 rather silly. This would mean that if you step out 1 foot into the
 water, you've left the state or country.



 indeed it seems to be different: en.wikipedia.org/wiki/Territorial_waters
 look at the internal waters in the diagram, those allow to reduce the
 admin-ways a lot by simplifying and not using the coastline.


Not quite. By default the baselines use the mean low-water line, basically
the coastlines, but not the coastlines in the OSM sense (high-water line).
Straight baselines *may* be used only in cases where the coastline is
deeply indented such as bays, coves, fjords, and the like, or if the state
claims to be an archipelagic state (whose baselines are all straight). So
for the more-or-less concave coastlines, the baselines would still be
complex. See: https://en.wikipedia.org/wiki/Baseline_%28sea%29
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Eugene Alvin Villar]

On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo 
cesar@gmail.com wrote:

 Eugene, I am also interested on your proposal to store on Wikidata a
 table/database similar to the one described on 1, so any further details on
 available infrastructure, technologies in use, work already done, etc are
 welcome.


Hi César, you can look at this Wikidata page for the German state of
Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985

It currently contains interesting properties and relationships that may be
what we need. Some interesting properties/relations are (especially the OSM
one):

country=Germany
capital=Stuttgart
type of administrative division=state of Germany
ISO 3166-2=DE-BW
GND identifier=4004176-1
contains administrative division=Regierungsbezirk Freiburg,
Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk
Tübingen
is in the administrative unit=Germany
OpenStreetMap Relation ID=62611
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Pieren]

On Thu, Oct 3, 2013 at 2:16 PM, Paul Norman penor...@mac.com wrote:

 Frankly, I find the idea of using the coastline as an admin boundary
 rather silly. This would mean that if you step out 1 foot into the
 water, you've left the state or country.

All the states or countries maps I've seen in my life used the
coastline. It does not mean that the sovereignty stops at the water
line. It's just a convention.

Pieren

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

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

2013/10/3 Pieren pier...@gmail.com

 All the states or countries maps I've seen in my life used the
 coastline. It does not mean that the sovereignty stops at the water
 line. It's just a convention.



how many states or country maps have you seen in scale 1:1000?

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Martin Koppenhoefer]

2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com

 well, maybe this is how things are correct? years ago I stumbled upon
 Liberia having a 200NM maritime border.



in reference to this I have found a document today stating that the
president of Liberia has released an executive order on Jan 10th 2013 which
seems to reduce their respective claims to the standard:
http://emansion.gov.lr/doc/Executive_Order_No._48.pdf

cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Maarten Deen]

On 2013-10-03 14:53, Martin Koppenhoefer wrote:

2013/10/3 Pieren pier...@gmail.com

All the states or countries maps I've seen in my life used the
coastline. It does not mean that the sovereignty stops at the water
line. It's just a convention.

how many states or country maps have you seen in scale 1:1000?


All maps I have seen make a clear distinction between land and sea. Only 
a very small number of maps I've seen actually show borders on 
international waters.


So it all depends on what you want to show and how you visualise it. If 
you make a map of Germany or the Netherlands with one color within the 
borders in the sense of territorial waters, I think few people would 
recognise them.
For the netherlands, you would have a smooth coastline without islands 
(Zeeland and Waddeneilanden).


Regards,
Maarten

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

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

The important issue here is that there is lots of potential uses here
(layers are not used exclusively for creating maps, they can also be used
for analysis) and there are people wishing to use these datasets: the
administrative boundaries based on coastline (call them whatever you want),
the ones based on the territorial waters, and possible others.

Because of this reason, it would be useful to have them explicitly mapped
on OSM. It is not the same to just extract a relation and descendants and
build some polygons from there, than to extract the coastline and the
borders that are not coastline and try to see how they fit within their
containing country. It is feasible, but not practical.

However, as you suggested, it is important to keep an eye on
maintainability of OSM data when creating these relations. A simple
approach would be to create land mass relations having other relations as
members. For instance, in Spain such relationship could be easily created
from the admin_level=4 relations, containing just 19 members (as subareas).
As far as the admin_level=4 relations are correct, the superrelation should
be correct (if not, they should be corrected anyway). I don't know if such
approach would be so feasible for other countries. Of course, proper
tagging should be applied to these relations in order to don't create
ambiguities.

César


2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com


 2013/10/3 Pieren pier...@gmail.com

 All the states or countries maps I've seen in my life used the
 coastline. It does not mean that the sovereignty stops at the water
 line. It's just a convention.



 how many states or country maps have you seen in scale 1:1000?

 cheers,
 Martin

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




-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-SIA: http://sia.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

That sounds interesting. I am not familiar with Nominatim, but I have
correctly understood, the result is a Postgres/postgis database with all
those polygons and hierarchies. This could be an interesting approach as
the post-processing could be directly done there using PostGIS predicates.

However, I am not sure about the generated hierarchies, as they don't keep
all OSM admin_levels into account (at least in the nomenclature: country,
state, county) and I see clear errors for Spain using the link [2] that you
provided. It would be interesting to know how these hierarchies are
generated (just OSM tags and geometric relations, external database, etc).

In any case, it seems a good starting point for my project.

Cheers,

Cesar


2013/10/3 Sarah Hoffmann lon...@denofr.de

 On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:
  Hi Frederik, regarding software, I am already familiar with Mapit scripts
  code, which are able to extract admin boundary polygons for each level
 (it
  is not creating relationships though). How do you see Nominatim or
  Osmium/osmjs better for the purpose?

 Nominatim already does a lot of the stuff you are planning to do. It
 creates geometries for admin boundaries from OSM data and puts them
 in a proper hierarchy. It is able to process updates and in the
 process makes sure that boundaries do not just disappear if somebody
 breaks the relation. If you only process the data that interests you
 (boundary=administrative and place nodes) it is not even that
 resource-hungry.

 It does have support for listing broken boundaries [1] and during the
 last hack day Brian has written a proof-of-concept for browsing admin
 hierarchies[2]. There is even a script to dump objects within a certain
 boundary[3] which could be easily extended to dump entire hierarchies.
 All these functions should currently be used with care though. There are
 known bugs and the output needs to be improved to make them really
 usable.

 Basically, most of the work to do would be on the output side, the
 heavy lifting of processing the data is already done. Well, apart
 from checking the OSM boundaries against reality. But I think wiki data
 is a good starting point for that.

  I will probably try the first option, but I expect that any of them would
  be costly to maintain if there are frequent changes of the tagging scheme
  for each country. (But nobody said it would be an easy task :-)

 Making boundary tagging more visible will hopefully help to stablize
 and unify the tagging schemas. The less country-specific exceptions
 the better.

 Sarah

 [1] http://nominatim.osm.org/polygons
 [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985
 (This is for demonstration only, please do not scrape. It will not
 always give you the expected results anyways because there
 is a
 known bug with parenting which still lingers in the DB.)
 [3]
 https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php

  2013/10/2 Frederik Ramm frede...@remote.org
 
   Hi,
  
   On 02.10.2013 18:23, César Martínez Izquierdo wrote:
I plan to create and make easily available a world-wide
 administrative
layer based on OSM data, ideally including existing administrative
 codes
(ISO, NUTS in Europe, etc) for each level and producing regular
 updates
(for instance once a year).
  
   This is something I have been thinking about for a long time (but never
   written any usable code).
  
   Nominatim is probably a good starting point - a better one than MapIt I
   should think.
  
   If you're only after extracting certain relation polygons then you
 could
   as well use osmjs (part of Osmium) and have it generate shape files for
   you, or adapt the shapefile/ogr export samples in Osmium; this will not
   yet give you a hierarchy, only individual boundaries, and you have to
   find out the hierarchy yourself.
  
   Finding out the hierarchy is going to be tricky. Nominatim does go to
   some lengths to do that already. It sounds easy (find all polygons
 with
   an admin level smaller than X where this polygon I'm looking at lies
   in). But in reality you will encounter at least:
  
   * missing polygons on all levels - sometimes simply not mapped,
   sometimes missing by design, e.g. Germany has some areas where admin
   levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
   a map of all admin_level 8 areas in Germany and you have lots of holes
   in them
  
   * broken polygons on all levels; brokenness changes by the day, i.e.
   what is working today may be broken tomorrow and vice versa
  
   * occasionally (e.g. Japan) linear regional boundaries that simply go
   from coast to coast without including the coastline
  
   * occasionally (e.g. Chile) a regional boundary that is not a
   multipolygon relation but instead a grouping of smaller regional
 entities
  
   * sometimes small geometric inaccuracies mean that 

Re: [OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

Thanks Eugene, that looks really promising.
I've seen there is an API to query Wikidata (results can be list of
Wikidata item IDs encoded as JSON), but I don't see the way to get the item
itself as JSON (or any other parseable format). Is it on the way?

César


2013/10/3 Eugene Alvin Villar sea...@gmail.com

 On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo 
 cesar@gmail.com wrote:

 Eugene, I am also interested on your proposal to store on Wikidata a
 table/database similar to the one described on 1, so any further details on
 available infrastructure, technologies in use, work already done, etc are
 welcome.


 Hi César, you can look at this Wikidata page for the German state of
 Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985

 It currently contains interesting properties and relationships that may be
 what we need. Some interesting properties/relations are (especially the OSM
 one):

 country=Germany
 capital=Stuttgart
 type of administrative division=state of Germany
 ISO 3166-2=DE-BW
 GND identifier=4004176-1
 contains administrative division=Regierungsbezirk Freiburg,
 Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk
 Tübingen
 is in the administrative unit=Germany
 OpenStreetMap Relation ID=62611




-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-SIA: http://sia.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Sarah Hoffmann]

On Thu, Oct 03, 2013 at 03:31:20PM +0200, César Martínez Izquierdo wrote:
 That sounds interesting. I am not familiar with Nominatim, but I have
 correctly understood, the result is a Postgres/postgis database with all
 those polygons and hierarchies. This could be an interesting approach as
 the post-processing could be directly done there using PostGIS predicates.

Yes, exactly.

 However, I am not sure about the generated hierarchies, as they don't keep
 all OSM admin_levels into account (at least in the nomenclature: country,
 state, county) 

It keeps the levels internally and also uses the full levels for the
hierarchies. The levels are only grouped for output.

 and I see clear errors for Spain using the link [2] that you
 provided. It would be interesting to know how these hierarchies are
 generated (just OSM tags and geometric relations, external database, etc).

The hierarchies are built with OSM data only using the tagged admin_levels and
relating the polygon geometries. Basically, the parent is defined as the
area that covers the object that has the next smaller admin_level. It
gets a bit more complicated when place nodes are involved.

Sarah


 2013/10/3 Sarah Hoffmann lon...@denofr.de
 
  On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:
   Hi Frederik, regarding software, I am already familiar with Mapit scripts
   code, which are able to extract admin boundary polygons for each level
  (it
   is not creating relationships though). How do you see Nominatim or
   Osmium/osmjs better for the purpose?
 
  Nominatim already does a lot of the stuff you are planning to do. It
  creates geometries for admin boundaries from OSM data and puts them
  in a proper hierarchy. It is able to process updates and in the
  process makes sure that boundaries do not just disappear if somebody
  breaks the relation. If you only process the data that interests you
  (boundary=administrative and place nodes) it is not even that
  resource-hungry.
 
  It does have support for listing broken boundaries [1] and during the
  last hack day Brian has written a proof-of-concept for browsing admin
  hierarchies[2]. There is even a script to dump objects within a certain
  boundary[3] which could be easily extended to dump entire hierarchies.
  All these functions should currently be used with care though. There are
  known bugs and the output needs to be improved to make them really
  usable.
 
  Basically, most of the work to do would be on the output side, the
  heavy lifting of processing the data is already done. Well, apart
  from checking the OSM boundaries against reality. But I think wiki data
  is a good starting point for that.
 
   I will probably try the first option, but I expect that any of them would
   be costly to maintain if there are frequent changes of the tagging scheme
   for each country. (But nobody said it would be an easy task :-)
 
  Making boundary tagging more visible will hopefully help to stablize
  and unify the tagging schemas. The less country-specific exceptions
  the better.
 
  Sarah
 
  [1] http://nominatim.osm.org/polygons
  [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985
  (This is for demonstration only, please do not scrape. It will not
  always give you the expected results anyways because there
  is a
  known bug with parenting which still lingers in the DB.)
  [3]
  https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php
 
   2013/10/2 Frederik Ramm frede...@remote.org
  
Hi,
   
On 02.10.2013 18:23, César Martínez Izquierdo wrote:
 I plan to create and make easily available a world-wide
  administrative
 layer based on OSM data, ideally including existing administrative
  codes
 (ISO, NUTS in Europe, etc) for each level and producing regular
  updates
 (for instance once a year).
   
This is something I have been thinking about for a long time (but never
written any usable code).
   
Nominatim is probably a good starting point - a better one than MapIt I
should think.
   
If you're only after extracting certain relation polygons then you
  could
as well use osmjs (part of Osmium) and have it generate shape files for
you, or adapt the shapefile/ogr export samples in Osmium; this will not
yet give you a hierarchy, only individual boundaries, and you have to
find out the hierarchy yourself.
   
Finding out the hierarchy is going to be tricky. Nominatim does go to
some lengths to do that already. It sounds easy (find all polygons
  with
an admin level smaller than X where this polygon I'm looking at lies
in). But in reality you will encounter at least:
   
* missing polygons on all levels - sometimes simply not mapped,
sometimes missing by design, e.g. Germany has some areas where admin
levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
a map of all 

Re: [OSM-talk] Administrative boundaries export

[Eugene Alvin Villar]

On Fri, Oct 4, 2013 at 1:35 AM, César Martínez Izquierdo 
cesar@gmail.com wrote:

 Thanks Eugene, that looks really promising.
 I've seen there is an API to query Wikidata (results can be list of
 Wikidata item IDs encoded as JSON), but I don't see the way to get the item
 itself as JSON (or any other parseable format). Is it on the way?


Unfortunately, I am not up-to-par with the API side of Wikidata. I assume
that every bit of data on Wikidata can or will be accessible through APIs.
Otherwise, it would limit the usefulness of Wikidata if we resort to
scraping the HTML page.



 2013/10/3 Eugene Alvin Villar sea...@gmail.com

 On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo 
 cesar@gmail.com wrote:

 Eugene, I am also interested on your proposal to store on Wikidata a
 table/database similar to the one described on 1, so any further details on
 available infrastructure, technologies in use, work already done, etc are
 welcome.


 Hi César, you can look at this Wikidata page for the German state of
 Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985

 It currently contains interesting properties and relationships that may
 be what we need. Some interesting properties/relations are (especially the
 OSM one):

 country=Germany
 capital=Stuttgart
 type of administrative division=state of Germany
 ISO 3166-2=DE-BW
 GND identifier=4004176-1
 contains administrative division=Regierungsbezirk Freiburg,
 Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk
 Tübingen
 is in the administrative unit=Germany
 OpenStreetMap Relation ID=62611


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

[OSM-talk] Administrative boundaries export

[César Martínez Izquierdo]

Hi,

I plan to create and make easily available a world-wide administrative
layer based on OSM data, ideally including existing administrative codes
(ISO, NUTS in Europe, etc) for each level and producing regular updates
(for instance once a year).

I think such a layer would be very useful for a number of scenarios, for
instance for scientific analysis involving administrative boundaries,
specially in areas where such data is not publicly available. Moreover, it
would probably attract collaborators to complete or correct the OSM
boundaries where needed.

I'd like to learn about similar initiatives (I don't want to replicate
efforts) or interested people, and also about existing tools for
simplifying the work. My first idea is to use Map-it scripts (which create
KML Admin Boundaries files from OSM data) as a basis for this work, but
other ideas are welcome.

Thanks in advance,

César Martínez Izquierdo

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-SIA: http://sia.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Simone Cortesi]

On Wed, Oct 2, 2013 at 6:23 PM, César Martínez Izquierdo
cesar@gmail.com wrote:
 I plan to create and make easily available a world-wide administrative layer
 based on OSM data, ideally including existing administrative codes (ISO,
 NUTS in Europe, etc) for each level and producing regular updates (for
 instance once a year).

thanks for jumping on this. I think this is a much needed export.

some thoughts:
1. admin data is stored with relations, which is not that easy to
maintain. you WILL always find broken borders.
2. having a web app to visualize that, and allow people to fix them is
something needed. similar to what we already have for the coastline.
3. once a year might be too much time between releases, think about a
once a year stable release, where all borders compile correctly.
4. show stats on broken, fixed borders.
5. provide them as a download in shapefile, poly format, geojson, and kml.

Thanks,
Simone.

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

Re: [OSM-talk] Administrative boundaries export

[Frederik Ramm]

Hi,

On 02.10.2013 18:23, César Martínez Izquierdo wrote:
 I plan to create and make easily available a world-wide administrative
 layer based on OSM data, ideally including existing administrative codes
 (ISO, NUTS in Europe, etc) for each level and producing regular updates
 (for instance once a year).

This is something I have been thinking about for a long time (but never
written any usable code).

Nominatim is probably a good starting point - a better one than MapIt I
should think.

If you're only after extracting certain relation polygons then you could
as well use osmjs (part of Osmium) and have it generate shape files for
you, or adapt the shapefile/ogr export samples in Osmium; this will not
yet give you a hierarchy, only individual boundaries, and you have to
find out the hierarchy yourself.

Finding out the hierarchy is going to be tricky. Nominatim does go to
some lengths to do that already. It sounds easy (find all polygons with
an admin level smaller than X where this polygon I'm looking at lies
in). But in reality you will encounter at least:

* missing polygons on all levels - sometimes simply not mapped,
sometimes missing by design, e.g. Germany has some areas where admin
levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
a map of all admin_level 8 areas in Germany and you have lots of holes
in them

* broken polygons on all levels; brokenness changes by the day, i.e.
what is working today may be broken tomorrow and vice versa

* occasionally (e.g. Japan) linear regional boundaries that simply go
from coast to coast without including the coastline

* occasionally (e.g. Chile) a regional boundary that is not a
multipolygon relation but instead a grouping of smaller regional entities

* sometimes small geometric inaccuracies mean that e.g. a state boundary
fails the is-in test for the country boundary because there's just a
little square metre somewhere that is mapped as belonging to the state
but not the country

* overlapping admin polygons of the same admin level

I think that ate the very least you need to run the evaluation regularly
and compare: Do I have new polygons this week - have others vanished,
and if so, is that because they were explicitly deleted/replaced, or
were they just accidentally broken and I should continue to use last week's?

What we would really need though, is something much bigger: A separate
database of admin hierarchies, where people could - in a crowdsourced
manner - record things like:

There is an adminlevel 2 entities called Germany
It is divided into 16 exclusive adminlevel 4 entities with the
following names: ...
These 16 entities cover the area of Germany completely (no holes or sea
areas that would be outside of one of the entities)
The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel
6 entities...

and so on. A tree of arbitrary size where people can add and edit at will.

Now you will say but this tree could be generated from OpenStreetMap,
and I grant that one could attempt to build such a tree but it will
always be faulty and reflect the current brokenness of geometries in
OSM. One could *start* with an OSM-generated tree, but after that, the
tree must be kept separate. People should be able to add stuff to the
tree even when it is not in OpenStreetMap - there should be an
adminlevel 8 boundary called so-and-so. A regularly-running process
would then compare the tree to OpenStreetMap, and generate error reports
that can be presented visually:

The tree says that there should be a region called X in Germany but OSM
doesn't have one.

There is an area here that is not covered by any adminlevel 4 area but
the tree says that taken together the adminlevel 4 areas must cover all
of the country.

The tree claims there should be a region called X but in OSM there's
only a region with the similar name Y, which one is correct?

and so on. - I would expect the tree to be much more stable than the
data in OSM. Most of all, the tree could be worked on independently,
even by people unfamiliar with OSM. Of course the tree could link to OSM
objects but these links would regularly be checked and perhaps even
changed by the automated comparison system.

As I said, a simple export is easy but it will have too many weaknesses
- you couldn't even say to what level a country is complete. Some
people have started to link regional boundaries in OSM together with
concepts like subarea but I don't think this can replace an external
country structure tree because the tree could describe what is expected
to be there whereas in OSM you never know if some thing is missing
because it doesn't exist (cf. my example about the missing admin6/8
boundaries in Germany) or if it just hasn't been mapped yet, or is broken.

It would be great to see someone drive this important topic but it
certainly isn't something you can set up in a week or two ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

Re: [OSM-talk] Administrative boundaries export

[Eugene Alvin Villar]

On Thu, Oct 3, 2013 at 3:58 AM, Frederik Ramm frede...@remote.org wrote:

 What we would really need though, is something much bigger: A separate
 database of admin hierarchies, where people could - in a crowdsourced
 manner - record things like:

 There is an adminlevel 2 entities called Germany
 It is divided into 16 exclusive adminlevel 4 entities with the
 following names: ...
 These 16 entities cover the area of Germany completely (no holes or sea
 areas that would be outside of one of the entities)
 The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel
 6 entities...

 and so on. A tree of arbitrary size where people can add and edit at will.


This seems exactly like the kind of data I expect Wikidata (a Wikimedia
Foundation project, spearheaded by Wikimedia Deutschland) to encode.


 Now you will say but this tree could be generated from OpenStreetMap,
 and I grant that one could attempt to build such a tree but it will
 always be faulty and reflect the current brokenness of geometries in
 OSM. One could *start* with an OSM-generated tree, but after that, the
 tree must be kept separate. People should be able to add stuff to the
 tree even when it is not in OpenStreetMap - there should be an
 adminlevel 8 boundary called so-and-so. A regularly-running process

would then compare the tree to OpenStreetMap, and generate error reports
 that can be presented visually: [...]

 I would expect the tree to be much more stable than the
 data in OSM. Most of all, the tree could be worked on independently,
 even by people unfamiliar with OSM. Of course the tree could link to OSM
 objects but these links would regularly be checked and perhaps even
 changed by the automated comparison system.


If this tree database will only be compared to OSM then it should be OK to
start it as a derivative of the OSM database (inheriting the ODbL license).
However, we lose the ability to compare this with other similar databases
like the Global Administrative Areas database (http://www.gadm.org/) as
another form of QA due to the license incompatibility.

I think it would be better if the tree were started in Wikidata (which is
CC0-licensed) or as a separate project released to the public domain or
CC0- or PDDL-licensed.

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

Re: [OSM-talk] Administrative boundaries export

[Dale Kunce]

The American Red Cross is dealing with this issue right now.

We've built a database using GADM, GAUL, and Natural Earth. We initially
wanted to rely heavily on OSM but because the relation breaks said it
proved problematic. We've parked the use of OSM in our boundary dataset so
that we can move forward with our implementation. We would love to help
build out a plausible solution if one can be developed.

The basic features of our current in production solution:

   - Name based lookup for anything in GADM, GAUL, Natural Earth, and
   GeoNames.
   - Ability to get the admin stack, all admin boundaries above the
   currently selected feature, geoname, or WKT.
   - Ability to look at all of the datasets through time to use GADM.
   - Ability to get any feature from any of the datasets in geoJSON format.


Our roadmap includes an API link to Nominatim and using the OSM polygon
boundaries to then parse against our internal system to get the admin
stack names and then going back to Nominatim to get the OSM geometry for
the given features. Not the most elegant solution but I think it should
work for most of our work where we want to use OSM admin boundaries.

The code for our project is available on our github page.
https://github.com/AmericanRedCross/GeoWebServices and
https://github.com/AmericanRedCross/GeoDB.




On Wed, Oct 2, 2013 at 4:01 PM, Eugene Alvin Villar sea...@gmail.comwrote:

 On Thu, Oct 3, 2013 at 3:58 AM, Frederik Ramm frede...@remote.org wrote:

 What we would really need though, is something much bigger: A separate
 database of admin hierarchies, where people could - in a crowdsourced
 manner - record things like:

 There is an adminlevel 2 entities called Germany
 It is divided into 16 exclusive adminlevel 4 entities with the
 following names: ...
 These 16 entities cover the area of Germany completely (no holes or sea
 areas that would be outside of one of the entities)
 The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel
 6 entities...

 and so on. A tree of arbitrary size where people can add and edit at will.


 This seems exactly like the kind of data I expect Wikidata (a Wikimedia
 Foundation project, spearheaded by Wikimedia Deutschland) to encode.


 Now you will say but this tree could be generated from OpenStreetMap,
 and I grant that one could attempt to build such a tree but it will
 always be faulty and reflect the current brokenness of geometries in
 OSM. One could *start* with an OSM-generated tree, but after that, the
 tree must be kept separate. People should be able to add stuff to the
 tree even when it is not in OpenStreetMap - there should be an
 adminlevel 8 boundary called so-and-so. A regularly-running process

 would then compare the tree to OpenStreetMap, and generate error reports
 that can be presented visually: [...]


 I would expect the tree to be much more stable than the
 data in OSM. Most of all, the tree could be worked on independently,
 even by people unfamiliar with OSM. Of course the tree could link to OSM
 objects but these links would regularly be checked and perhaps even
 changed by the automated comparison system.


 If this tree database will only be compared to OSM then it should be OK to
 start it as a derivative of the OSM database (inheriting the ODbL license).
 However, we lose the ability to compare this with other similar databases
 like the Global Administrative Areas database (http://www.gadm.org/) as
 another form of QA due to the license incompatibility.

 I think it would be better if the tree were started in Wikidata (which is
 CC0-licensed) or as a separate project released to the public domain or
 CC0- or PDDL-licensed.

 Eugene

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




-- 
sent from my mobile device

Dale Kunce
http://normalhabit.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Christian Quest]

Frederik explained many of the usual troubles you may encounter. Sorry to
had many a few more :(

I recently had to deal with admin boundaries and the lack of homogeneous
tagging of worldwide reference numbers (like iso3166 or FIPS) does not help.
For example US states had only the usual 2 letters in the ref=* tag, no
fips code (which is a US federal classification) nor iso3166... so I added
fips codes to US states.

We could already start by making sure these worldwide references are
present in OSM data, and do some QA on them (make sure none is missing,
valid polygons, etc).

To help you, have a look at http://layers.openstreetmap.fr/ which renders
admin_level from 2 to 10...

See for example level 4 in Europe:
http://layers.openstreetmap.fr/?zoom=6lat=48.21736lon=2.70236layers=0B000T

UK level 4 is on the maritime borders (island culture ?) where most other
European countries stop on the coastline... tagging bio-diversity is not
helpful !



2013/10/2 César Martínez Izquierdo cesar@gmail.com

 Hi,

 I plan to create and make easily available a world-wide administrative
 layer based on OSM data, ideally including existing administrative codes
 (ISO, NUTS in Europe, etc) for each level and producing regular updates
 (for instance once a year).

 I think such a layer would be very useful for a number of scenarios, for
 instance for scientific analysis involving administrative boundaries,
 specially in areas where such data is not publicly available. Moreover, it
 would probably attract collaborators to complete or correct the OSM
 boundaries where needed.

 I'd like to learn about similar initiatives (I don't want to replicate
 efforts) or interested people, and also about existing tools for
 simplifying the work. My first idea is to use Map-it scripts (which create
 KML Admin Boundaries files from OSM data) as a basis for this work, but
 other ideas are welcome.

 Thanks in advance,

 César Martínez Izquierdo

 --
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
César Martínez Izquierdo
GIS developer
-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
ETC-SIA: http://sia.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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




-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Administrative boundaries export

[Eugene Alvin Villar]

On Thu, Oct 3, 2013 at 6:52 AM, Christian Quest cqu...@openstreetmap.frwrote:

 UK level 4 is on the maritime borders (island culture ?) where most other
 European countries stop on the coastline... tagging bio-diversity is not
 helpful !


This is actually another point to consider when extracting admin boundaries
from OSM data.

My personal view is that the admin boundary marks the boundary where the
administrative entity exercises jurisdiction. Under UNCLOS, nations are
allowed to exercise full sovereignty over internal waters (which includes
water seaward of the coastline but within the baselines) and almost full
sovereignty (foreign ships are allowed innocent passage) for territorial
waters (up to 12 nautical miles from the baselines). So I think that using
the maritime boundaries as the admin_level=2 boundary is not incorrect and
this is reflected in OSM.

Use of maritime boundaries for admin_level=3 and higher (such as with UK)
depends on how the particular nation interprets its internal
maritime/fisheries laws. In my country, we have municipal waters which
can be up to 15 kilometers from the shoreline and that's where
municipalities can exercise jurisdiction.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Boundaries ...

[Chris Hill]

Lester Caine les...@lsces.co.uk wrote:

OK
I'm buried deep into this and getting totally lost ...

I'm using http://layers.openstreetmap.fr/ to check what needs doing

We have 'admin?' levels

5=Regions ... so West Midlands
6=Counties ... But Manchester and some Welsh ones are missing?
7=Not used ... But I wonder if 'Unitary Authorities' might be better
here?
8='Districts' ... But I'm not sure WHAT is currently set here?
Should this be 'local_authority'?

9=Not Used
10=Parish ... Has some way to go, but why is CP appended to some areas
and not 
others? The files I've checked have CP as part of the title so should
we not 
standardise on that?

The French have added a separate 'local_authority'
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlocal_authority
But we have been having a discussion on the main talk list about them
doing 
their own thing ;)
We could legitimise that by using it?

I then have
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical
With political_division of:
parl_const
county_division
ward

But we only seem to have a very small number of wards loaded?

My immediate 'need' is to add a couple of constituencies and their
wards , but 
I'm having trouble unravelling the 9 different data sets in the
Boundary Line set.
I think I need 'district_borough_unitary_ward_region' for the wards,
but is it 
then 'westminster_const_region' for the constituency boundaries?

Next step is what has already been converted and who is already adding
stuff ...
I've located 'county', district' and 'parish' but I assume that I need
to 
process the ward data myself :)

CP is appended on some parishes because that is the name from the OS OpenData 
Boundary Line. The name IMHO is better without the CP.
-- 
Cheers, Chris
OSM User chillly

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

Re: [Talk-GB] Boundaries ...

[Brian Quinion]

On 23 September 2012 15:21, Colin Smale colin.sm...@xs4all.nl wrote:
 CP is part of the name in the OS Boundary-Line data. There doesn't seem to
 be any consensus or guidelines about what to put in the name tag. Should
 it be Dartford or Dartford Borough or Borough of Dartford or Dartford
 Council or something else? Is it naming the area, or the administrative
 entity governing it? As there are very many cases of areas at many levels
 named identically, from counties down to parishes, there needs to be some
 way of distinguishing between them.

 We have to watch out that we continue to distinguish distinct, unrelated
 hierarchies. In particular parish and ward mean different things
 according to the context. There are civil parishes, which are (by
 definition) a subarea of a higher-level local authority (normally
 district/borough or unitary authority) and ecclesiastical parishes: each
 religion/denomination has its own hierarchy of areas. The NHS has a
 geographic hierarchy as has Fire and Rescue. But they have only a certain
 correlation to governmental areas, with cases of one fire service serving
 multiple counties, and a counties being covered by multiple fire services
 (although I don't have an example of this to hand).

 An area at admin level 10 might be a civil parish, it might be an
 ecclesiastical parish, it might be an electoral ward etc etc. To me,
 boundary=administrative means the boundary belongs to government, which
 means it starts at level 2 with countries (leaving room for supra-national
 levels such as the EU) and includes regions, counties, unitary authorities,
 districts and civil parishes. Wards in this hierarchy should really be at
 admin level 11 (i.e. inferior to parishes). There are some special cases
 which don't fit the 100%: the Scilly Isles and City of London spring to
 mind. There is a hierarchy of parliamentary-electoral areas as well; the
 lowest quantum is the ward but these are not the same as the wards for
 local council purposes.

Personally, and as the maintainer of nominatim I would be very happy
to see admin_level dropped in favour of a set of specific tags (i.e.
place=* or something similar).  Admin_level is applied inconsistently
and in ways that cause overlapping hierarchies.  They also correlate
badly between the place nodes and boundary relations - using a
consistent set of tags across both would help no end in parsing the
data!

The current version of nominatim starts the process of linking admin
boundaries to nodes - the next version will probably depreciate
admin_level in favour of the place=* value from the label node where
it is available.

--
 Brian

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

Re: [OSM-talk] OSMI Boundaries Views

[sly (sylvain letuffe)]

Hi Markus,

   But osmi bundles together all relation
  above admin_level=4 (Swedish municipalities are on level 7) 

Just for you information in case that might suits your needs :
http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data

The coverage is world wide, and admin_level 4,5,6,7,8,10 are in seperate 
layers.
This tool was created for France at first, but then extended to world coverage.
In case you absolutely need the admin_level 9 (not used in France) I can add 
it if that's needed.



-- 
sly (sylvain letuffe)

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

Re: [OSM-talk] OSMI Boundaries Views

[Markus Lindholm]

On 22 September 2012 11:30, sly (sylvain letuffe) li...@letuffe.org wrote:
 Hi Markus,

   But osmi bundles together all relation
  above admin_level=4 (Swedish municipalities are on level 7)

 Just for you information in case that might suits your needs :
 http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data


I didn't know, thanks for the info. It suits my needs very well,
spotted right away that Sollefteå needs a bit of attention. Thanks
again.

/Markus

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

Re: [OSM-talk] OSMI Boundaries Views

[Lester Caine]

sly (sylvain letuffe) wrote:

Just for you information in case that might suits your needs :
http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data


Magic ... just what I was asking about on the gb list ;)
I need to add ward boundaries and this shows they ARE missing.

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-it] Boundaries

[Alexander Roalter]

Am 25.07.2012 00:56, schrieb Alexander Roalter:

On 07/24/2012 09:35 PM, Matteo Gottardi wrote:

Non ne sono sicuro al 100%, ma credo che una particella possa trovarsi
in un solo comune _catastale_, ma non è detto che quest'ultimo
coincida con quello amministrativo.


Questo è un'ottimo argomento. Nel caso da me indicato, proprio non lo
so, ma potrò chiedere a qualcuno, forse si può dare più luce a questo
affare.



Includo qui la risposta ricevuta dal comune di Chienes:

 habe die von Dir angegebene streetmap mit der Katastermappe im
 Bereich der Gp.293 und 198 K.G.Ehrenburg verglichen (siehe Anlage
 Katastermappe)

 bin der Meinung dass in dem Bereich beides übereinstimmt
 natürlich ist es so, dass alle Parzellen unserer Katastergemeinden
 Kiens, Ehrenburg, Getzenberg, St.Sigmund und Hofern die Gesamtfläche 
 der Gemeinde Kiens bilden

 in dem angegebenen Bereich bildet die Grenze der Katastergemeinde
 Ehrenburg zugleich auch die Gemeindegrenze zu St.Lorenzen

in sintesi: secondo il signor Mutschlechner dall'ufficio tecnico la 
confine come presentata su OSM è corretta (l'ho modificata io ad 
includere le parcelle in questione).


Poi fa la menzione che l'insieme delle comuni catastali costituisce 
l'intero comune di chienes. Poi c'è un allegato che mostra il confine, 
che a mio parere è identico a quello in OSM. Se a qualcuno interessa, 
posso spedirlo.


--
cheers,
Alex

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

Re: [Talk-it] Boundaries

[Carlo Stemberger]

On 24/07/2012 21:35, Matteo Gottardi wrote:
Nel caso il fiume cambiasse il suo corso, non ho idea di cosa 
succederebbe ai confini :) 


Sono piuttosto sicuro che il confine si sposti assieme al fiume: ricordo 
benissimo che questo concetto era stato spiegato durante una lezione di 
economia agraria. Non ho però sotto mano i riferimenti normativi: se 
qualcuno li trovasse, sarebbe utile.



Ciao!

Carlo

--
 .'  `.   | Registered Linux User #443882
 |a_a  |  | http://counter.li.org/  .''`.
 \_)__/  +--- : :'  :
 /(   )\  ---+ `. `'`
|\`/\  Registered Debian User #9 |   `-
\_|=='|_/   http://debiancounter.altervista.org/ |


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

Re: [Talk-it] Boundaries

[Damjan Gerl]

Carlo Stemberger, on 25/07/2012 12.36, wrote:

On 24/07/2012 21:35, Matteo Gottardi wrote:
Nel caso il fiume cambiasse il suo corso, non ho idea di cosa 
succederebbe ai confini :) 


Sono piuttosto sicuro che il confine si sposti assieme al fiume: 
ricordo benissimo che questo concetto era stato spiegato durante una 
lezione di economia agraria. Non ho però sotto mano i riferimenti 
normativi: se qualcuno li trovasse, sarebbe utile.



Ciao!

Carlo



Io non lo so, ma mi ricordo di aver visto da qualche parte in Europa che 
il confine (tra stati) era rimasto uno, mentre il fiume aveva cambiato 
corso. Forse era qui, ma non saprei se sia questo il caso...:

http://www.openstreetmap.org/?lat=46.4902lon=16.5308zoom=13layers=M

Damjan

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

Re: [Talk-it] Boundaries

[Alexander Roalter]

Am 25.07.2012 12:36, schrieb Carlo Stemberger:

On 24/07/2012 21:35, Matteo Gottardi wrote:

Nel caso il fiume cambiasse il suo corso, non ho idea di cosa
succederebbe ai confini :)


Sono piuttosto sicuro che il confine si sposti assieme al fiume: ricordo
benissimo che questo concetto era stato spiegato durante una lezione di
economia agraria. Non ho però sotto mano i riferimenti normativi: se
qualcuno li trovasse, sarebbe utile.

Negli USA ci sono parecchie dove il confine è stato definito dal fiume 
nelle sue estenzioni nel XIX o XVIII secolo, e non coincide più con il 
percorso attuale.. (per esempio 
qui:http://www.openstreetmap.org/?lat=34.7664lon=-90.4075zoom=12layers=M). 
Tra l'Indiana e Kentucky, è stato definito dal lato DX del fiume Ohio, 
ma anche nel 18??, e poi, quando il livello d'aqua è salito, il confinef 
oggi si trova alcuni metri dalla riva.


Ho letto da qualche altra parte che il confine in un fiume (almeno tra 
stati) può variare col tempo, ma verrà aggiustato regolarmente. Quando 
la differenza è troppo grande, c'è la possibilità di scambio di alcuni 
terreni per ripristinare le proporzioni originali.


--
cheers,
Alex

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

Re: [Talk-it] Boundaries

[Matteo Gottardi]

Il 22 luglio 2012 22:16, Alexander Roalter alexan...@roalter.it ha scritto:

 Mi sai dire quali comuni altoatesini mancano? Non ho accesso a un
 shape-file, ma un server WMS della provincia con le confini comunali (e
 partemente anche le confini dei frazioni (se sono stati comuni autonomi
[]

Chiedo scusa, si è trattato di un mio errore, i confini altoatesini
sono a posto. C'erano delle way non taggate come
boundary=administrative ma correttamente inserite nella relativa
relation, e lo script che uso per controllare i confini non le
considerava.

Penso comunque di procedere all'import dei dati istat 2011 in versione
non generalizzata, sono molto più precisi rispetto a quelli del 2001.

PS: attenzione con il server wms della provincia, nei metadati di
parecchi layer (compreso quello delle unità amministrative) c'è
scritto Modello dati ancora proprietario.

-- 
* Matteo Gottardi | matg...@tin.it
* ICQ UIN 20381372
* Linux - the choice of a GNU generation
* GPG Fingerprint:
* B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1

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

Re: [Talk-it] Boundaries

[Alexander Roalter]

Am 24.07.2012 08:18, schrieb Matteo Gottardi:

Il 22 luglio 2012 22:16, Alexander Roalter alexan...@roalter.it ha scritto:

PS: attenzione con il server wms della provincia, nei metadati di
parecchi layer (compreso quello delle unità amministrative) c'è
scritto Modello dati ancora proprietario.



Ok, l'ho appena visto.

Un'altra cosa: quale miglioramento si può aspettare dagli nuovi dati ISTAT?
Per esempio qui alla confine Chienes/San Lorenzo 
(http://www.openstreetmap.org/?lat=46.78733lon=11.86212zoom=17layers=M) 
c'è una tratta che si estende per circa 250x50 metri a est, e che non è 
visibile nel layer dell unità amministrative, ma guardando nel catastro, 
si vede che quel pezzo fa parte delle parcelle 293 e 198/1 del comune di 
chienes (o meglio: comune catastale di casteldarne).


Una parcella può trovarsi solo in un comune, così questo pezzo come si 
trova adesso a OSM è corretto.


E un'ultima domanda: è ragionevole usare i fiumi come membro della 
relazione se il fiume è parte integrale della definizione del confine? 
I.E. se il fiume cambiasse il suo percorso, anche la confine dovrebbe 
cambiare? Questo, almeno nel XIX secolo (e forse anche nel XX secolo) 
era il caso con il confine tra vipiteno e stilves/campo trens.



--
cheers,
Alex

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

Re: [Talk-it] Boundaries

[Carlo Stemberger]

On 24/07/2012 12:37, Alexander Roalter wrote:


E un'ultima domanda: è ragionevole usare i fiumi come membro della 
relazione se il fiume è parte integrale della definizione del confine? 
I.E. se il fiume cambiasse il suo percorso, anche la confine dovrebbe 
cambiare?


Sì.

Carlo

--
 .'  `.   | Registered Linux User #443882
 |a_a  |  | http://counter.li.org/  .''`.
 \_)__/  +--- : :'  :
 /(   )\  ---+ `. `'`
|\`/\  Registered Debian User #9 |   `-
\_|=='|_/   http://debiancounter.altervista.org/ |


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

Re: [Talk-it] Boundaries

[Guido Piazzi]

Il 24/07/2012 15:03, Carlo Stemberger ha scritto:

On 24/07/2012 12:37, Alexander Roalter wrote:


E un'ultima domanda: è ragionevole usare i fiumi come membro della
relazione se il fiume è parte integrale della definizione del confine?
I.E. se il fiume cambiasse il suo percorso, anche la confine dovrebbe
cambiare?


Sì.


A me (che spesso ho a che fare con questioni come queste per lavoro) 
risulta di no: il fiume cambia corso ma il confine rimane dov'è.


Ma in molti tratti, dove il corso del fiume non è mutato, la risposta 
può essere sì: il confine si trova in mezzo al fiume, e nessuno ha mai 
messo dei termini per individuarlo con precisione, quindi la stessa 
linea può rappresentare il waterway=river e fare parte della relazione 
che individua il confine.


Guido


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

Re: [Talk-it] Boundaries

[Matteo Gottardi]

Il 24 luglio 2012 12:37, Alexander Roalter alexan...@roalter.it ha scritto:

 Un'altra cosa: quale miglioramento si può aspettare dagli nuovi dati ISTAT?

I nuovi dati sono molto più particolareggiati rispetto a quelli attuali.
Ho messo su http://www.gomatteo.net/new.gpx.gz e
http://www.gomatteo.net/old.gpx.gz i confini nuovi e quelli correnti.
Se provi a confrontarli ti rendi conto di come i vecchi siano molto
approssimativi, mentre i nuovi seguono spesso elementi naturali (come
fiumi o creste) o artificiali (es. strade).

 Una parcella può trovarsi solo in un comune, così questo pezzo come si trova
 adesso a OSM è corretto.

Non ne sono sicuro al 100%, ma credo che una particella possa trovarsi
in un solo comune _catastale_, ma non è detto che quest'ultimo
coincida con quello amministrativo.
Comunque è possibilissimo che si tratti di un errore/approssimazione
dei confini istat.

 E un'ultima domanda: è ragionevole usare i fiumi come membro della relazione
 se il fiume è parte integrale della definizione del confine? I.E. se il
 fiume cambiasse il suo percorso, anche la confine dovrebbe cambiare? Questo,

Credo sia corretto inserirlo nella relazione: se il fiume demarca un
confine, è giusto che confine e fiume coincidano topologicamente.

Nel caso il fiume cambiasse il suo corso, non ho idea di cosa
succederebbe ai confini :)

Ciao,
  Teo

-- 
* Matteo Gottardi | matg...@tin.it
* ICQ UIN 20381372
* Linux - the choice of a GNU generation
* GPG Fingerprint:
* B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1

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

Re: [Talk-it] Boundaries

[Alexander Roalter]

On 07/24/2012 09:35 PM, Matteo Gottardi wrote:

Non ne sono sicuro al 100%, ma credo che una particella possa trovarsi
in un solo comune _catastale_, ma non è detto che quest'ultimo
coincida con quello amministrativo.


Questo è un'ottimo argomento. Nel caso da me indicato, proprio non lo 
so, ma potrò chiedere a qualcuno, forse si può dare più luce a questo 
affare.



--
Cheers,
Alex


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

Re: [Talk-it] Boundaries

[Alexander Roalter]

On 07/22/2012 06:36 PM, Matteo Gottardi wrote:

http://www3.istat.it/ambiente/cartografia/versione_non_generalizzata.html
), iniziando dal Südtirol - Alto Adige, dove mancano parecchi comuni.


Mi sai dire quali comuni altoatesini mancano? Non ho accesso a un 
shape-file, ma un server WMS della provincia con le confini comunali (e 
partemente anche le confini dei frazioni (se sono stati comuni autonomi 
prima del 1927), e le ho solo aggiustate per le comuni della val 
pusteria e alcuni dell'alta valle d'isarco: Rio Pusteria, Vandoies, 
Chienes, Rodengo, San Lorenzo di Sebato, Falzes, Naz-Sciaves, Varna, 
Fortezza, Gais, Marebbe, Valdaora, Villabassa, Monguelfo-Tesido, Valle 
di Casies, San Candido, Sesto, Dobbiaco, Rasun-Anterselva, Perca, Braies.



--
Cheers,
Alex


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

Re: [OSM-talk] International Boundaries from Department of State

[Arun Ganesh]

Regarding the administrative boundaries, why is there no mention of the GADM
dataset[1] as a potential data source? Its the most accurate and detailed
public domain set of worldwide boundaries that I have come across.

[1]http://www.gadm.org/

-- 
j.mp/ArunGanesh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] International Boundaries from Department of State

[Chris Hill]

The terms of use say only for non-commercial use, which is not acceptable for 
use in OSM

Arun Ganesh arun.plane...@gmail.com wrote:

Regarding the administrative boundaries, why is there no mention of the
GADM
dataset[1] as a potential data source? Its the most accurate and
detailed
public domain set of worldwide boundaries that I have come across.

[1]http://www.gadm.org/

-- 


-- 
Cheers, Chris (osm:chillly)

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

Re: [OSM-talk] International Boundaries from Department of State

[Arun Ganesh]

On Thu, Sep 29, 2011 at 6:15 PM, Chris Hill o...@raggedred.net wrote:

 The terms of use say only for non-commercial use, which is not acceptable
 for use in OSM


Ah missed that, the page on wikipedia said public domain. There's
surprisingly scarce info about the GADM project, no mention of sources, how
it was done, or the people behind it.

-- 
j.mp/ArunGanesh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] International Boundaries from Department of State

[Mikel Maron]

Hi

The US Department of State has recently provided us with their most recent 
international boundaries data sets. 

This includes a more accurate South Sudan boundary, which could be used to 
update the OSM boundary (which has a slight error in the West).
The data is all public domain.


More details, and download links, are on the wiki.

 http://wiki.openstreetmap.org/wiki/Potential_Datasources#US_Dept._of_State.2C_International_Boundaries

-Mikel


== Mikel Maron ==
+14152835207 @mikel s:mikelmaron___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Boundaries for Forestry Commission land

[Frederik Ramm]

Peter,

Peter Miller wrote:

See you in court then ;)


Legal-talk, rather - I've opened up a new thread there!

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

Re: [Talk-GB] Boundaries for Forestry Commission land

[Andy Allan]

On Sun, Jan 30, 2011 at 11:15 AM, Andrew Black
andrewdbl...@googlemail.com wrote:
 On 29 January 2011 17:40, Steve Chilton s.l.chil...@mdx.ac.uk wrote:
 Not open, but available at magic.defra.co.uk:
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=24
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=25

 Excuse my ignorance - if the data is not open, how can it be used for
 OSM (or have I missed the point of the question)

I suspect Peter wanted it for a different purpose than adding it to
OSM - his original request was for it as either open or closed data
after all.

Cheers,
Andy

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

Re: [Talk-GB] Boundaries for Forestry Commission land

[Peter Miller]

Just what I needed.

Many thanks,

Peter


On 29 January 2011 17:40, Steve Chilton s.l.chil...@mdx.ac.uk wrote:

 Not open, but available at magic.defra.co.uk:
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=24
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=25

 Cheers
 STEVE

 
 From: Peter Miller [peter.mil...@itoworld.com]
 Sent: Saturday, January 29, 2011 2:18 PM
 To: Talk-GB@openstreetmap.org
 Subject: [Talk-GB] Boundaries for Forestry Commission land

 Is anyone aware of a place where one can download the boundaries of the
 Forestry Commission land (be it as open data or as closed data)?

 If not then I will do a FOI request for it.


 Regards,



 Peter


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

Re: [Talk-GB] Boundaries for Forestry Commission land

[Andrew Black]

On 29 January 2011 17:40, Steve Chilton s.l.chil...@mdx.ac.uk wrote:
 Not open, but available at magic.defra.co.uk:
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=24
 http://magic.defra.gov.uk/datadoc/metadata.asp?dataset=25

Excuse my ignorance - if the data is not open, how can it be used for
OSM (or have I missed the point of the question)

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

[Talk-GB] Boundaries for Forestry Commission land

[Peter Miller]

Is anyone aware of a place where one can download the boundaries of the
Forestry Commission land (be it as open data or as closed data)?

If not then I will do a FOI request for it.


Regards,



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