OSM doesn't so much "handle" disputed boundaries, as permit them. Admin
boundaries can overlap. Boundaries can be tagged as disputed.
Mapnik doesn't do anything in particular with such information however.
A good example is in East Jerusalem. Both the 1949 line and the 1967 are
present and tagged as admin_level=2, and both ways are part of different
relations.
http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=35.23757&lat=31.75886&zoom=12
So the PA and Israel overlap in East Jerusalem. This has resulted in some
interesting situations, like nominatim saying that the Western Wall is in the
West Bank :)
In Kashmir, the line of control is mapped as admin_level=2, and tagged as
dispute=yes. Again, nothing in particular done with this by default rendering.
http://www.openstreetmap.org/browse/way/132965073
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron
>________________________________
> From: Brad Thompson <[email protected]>
>To: [email protected]; [email protected]
>Sent: Thursday, March 7, 2013 8:17 PM
>Subject: Re: [OHM] Historic Digest, Vol 8, Issue 5
>
>
>Sean --
>
>
>Hmm. Well, now that I look more closely, I'm a little stumped. I went to
>inspect some border ways around Kashmir, then again around Tibet, imagining
>that I'd find classifications for multiple conflicting lines. But I can't
>quite figure it out, and can't separate out any differing shapes. Examples and
>reference:
>
>
>http://www.openstreetmap.org/browse/relation/1943188
>http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=78.74625&lat=35.50191&zoom=7
>
>
>
>Mikel, can you shed any light on the topic of how OSM handles disputed
>boundaries?
>
>
>
>Brad
>
>
>On Wed, Mar 6, 2013 at 4:00 AM, <[email protected]> wrote:
>
>
>>Message: 1
>>Date: Tue, 5 Mar 2013 09:21:02 -0700
>>From: Sean Gillies <[email protected]>
>>To: Brad Thompson <[email protected]>
>>Cc: [email protected]
>>Subject: Re: [OHM] Mapping what's on the ground and other good
>> practices
>>Message-ID:
>> <caoodmjqouwitkavzg-sp2l7qwaey4mnsxhgfdwz2letynfh...@mail.gmail.com>
>>Content-Type: text/plain; charset=ISO-8859-1
>>
>>Brad,
>>
>>I admit that I don't know the disputed borders in OSM well enough to
>>judge whether the same conventions would work for uncertain historical
>>data. Can you you point me to a map region that has overlapping
>>national borders? I'd like to look at their tags and try to understand
>>how Chinese and Indian maps would get their preferred boundaries.
>>
>>On Fri, Mar 1, 2013 at 5:56 PM, Brad Thompson <[email protected]> wrote:
>>> Sean, I really like your proposed best practices '"Map strong and
>>> falsifiable hypotheses about what was on the ground', and completely agree
>>> that a structure for citation will be critical because of the nature of the
>>> subject matter.
>>>
>>> I also agree that lack of consensus will be a more likely scenario than real
>>> controversy, but the if the point of OHM will be to allow those conflicts to
>>> be stored and managed easily (dare I hijack the phrase 'Teach the
>>> Controversy'?), then the mechanics of presenting the differing positions
>>> should be the same, right? In any case, I would imagine that most conflict
>>> would be related to these three questions:
>>>
>>> How the thing existed / changed (e.g., the shapes of river alignments, sizes
>>> of buildings, pioneer land claims)
>>> Whether the thing existed / changed at all (e.g., Dolores Lagoon, El Dorado)
>>> When the thing existed / changed (e.g., Sarah Ann Island, Beringia)
>>>
>>>
>>> One way or another, multiple versions of spatial 'fact' will need to be
>>> addressed. On one hand, as Mikel has pointed out, we have a clear need for
>>> the same kind of localization as the current, temporally static OSM, albeit
>>> on a larger scale, (imagine the whole world as Kashmir). But in addition to
>>> that, there's the issue of speculative maps and configurations of the
>>> physical world that didn't happen. Specifically, I'm thinking of all of the
>>> urban planning proposals from the 1960s that never saw the light of day, but
>>> there are applications for older eras too (for instance, unrealized
>>> territorial aspirations during the Napoleonic or World Wars).
>>>
>>> This image keeps coming to my mind as I think through this --
>>> http://i.imgur.com/3702A.jpg
>>>
>>> Could the current OSM capacity for displaying multiple disputed boundaries
>>> be modified to present multiple scenarios? Or is this all too complicated to
>>> be contained by it?
>>>
>>> - Brad
>>>
>>> _______________________________________________
>>> Historic mailing list
>>> [email protected]
>>> http://lists.openstreetmap.org/listinfo/historic
>>>
>>
>>
>>
>>--
>>Sean Gillies
>>
>>
>>
>>------------------------------
>>
>>Message: 2
>>Date: Tue, 5 Mar 2013 23:05:09 -0400
>>From: Rob Warren <[email protected]>
>>To: johnny0 <[email protected]>
>>Cc: [email protected], [email protected]
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <[email protected]>
>>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>
>>I've been looking at the OSM documentation. It would seem that we can
>>use start_data and end_date for both ways and relations. It might make
>>things easier to have ways (de)activate based on the date where things
>>changed and have the relation live on through different incarnations.
>>
>>Keep in mind through that datums are messy (even in WGS84), you are
>>unlikely to notice the San Francisco slip unless your data source is
>>very good. Maps in the early 1900 had limited accuracy; the ones I
>>used were aiming for ~20 yards.
>>
>>This brings the annoying question of whether we should be recording
>>accuracy of ways / node positions. I've been searching the OSM wiki
>>for standards and/or best practices about this without any success.
>>Any ideas out there?
>>
>>
>>best,
>>rhw
>>
>>On 4-Mar-13, at 4:26 PM, johnny0 wrote:
>>
>>> It's not just shifting borders. What about changing physical
>>> geography?
>>>
>>> How best to handle changing coastlines over time? I'm thinking of
>>> sunken Roman era ports.
>>>
>>> http://ac-support.europe.umuc.edu/~jmatthew/naples/pozzport.htm
>>>
>>> As well as man-made land:
>>>
>>> http://blog.sfgate.com/ontheblock/2011/02/25/does-your-house-sit-on-landfill/
>>>
>>> Also, shifting rivers:
>>>
>>> http://blogfishx.blogspot.com/2011/05/will-mississippi-river-change-course.html
>>>
>>> And what about earthquakes? There was 2 to 32 feet of horizontal
>>> slip in the 1906 San Francisco earthquake.
>>>
>>> http://earthquake.usgs.gov/regional/nca/virtualtour/earthquake.php
>>>
>>> This last one is tricky.
>>>
>>> -John
>>>
>>> On 2013-03-04, at 12:07 PM, Rob Warren <[email protected]>
>>> wrote:
>>>
>>>>
>>>> I'd like to get it to that point, especially in recording the
>>>> changes in the spatial objects over time.
>>>>
>>>> The other issue is that while a contributor might add the border of
>>>> the Kingdom of Prussia and another the border of the Free State of
>>>> Prussia, the ways that are common to both objects will eventually
>>>> need to be merged. This is going to require some creativity, but it
>>>> is doable. I also suspect that eventually we'll have a few
>>>> different 'application websites' that use the OHM back-end for
>>>> storage but render application specific timelines only.
>>>>
>>>> I'd suggest we start by putting in some data and we'll build the
>>>> tools as we go along.
>>>>
>>>> rhw
>>>>
>>>>
>>>> On 28-Feb-13, at 9:11 PM, [email protected] wrote:
>>>>
>>>>> Message: 2
>>>>> Date: Thu, 28 Feb 2013 16:52:27 -0600
>>>>> From: Ed Dykhuizen <[email protected]>
>>>>> To: Burrito Justice <[email protected]>
>>>>> Cc: "[email protected]" <[email protected]>,
>>>>> Joseph
>>>>> Pettigrew <[email protected]>
>>>>> Subject: Re: [OHM] [Historic] Historic Digest, Vol 7, Issue 9
>>>>> Message-ID:
>>>>> <CAHDqN=8gEhHzJeazX6-s8RCu00uE0B-
>>>>> [email protected]>
>>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I don't know if I should be counted towards any quorum of any kind
>>>>> -- I'm
>>>>> not a developer, just someone interested in this topic and very
>>>>> happy to
>>>>> see it being pursued. Specifically, I had an idea a while ago about
>>>>> creating political maps for each year throughout history. So you
>>>>> could look
>>>>> at a political map of Europe around 343 BC and then move a dial
>>>>> towards the
>>>>> same area around 323 BC and see how the political map changed as
>>>>> Alexander
>>>>> the Great went on his conquerin' spree. I'm a big history fan, and
>>>>> more of
>>>>> a visual learner, so something like this would really help me
>>>>> solidify a
>>>>> lot of world history.
>>>>>
>>>>> Granted, creating political maps for every year in history is a
>>>>> Herculean
>>>>> task. So I was hoping someone could develop an interface that
>>>>> would allow
>>>>> non-tech-savvy people like myself to make such changes. You know,
>>>>> something
>>>>> where I could go to the map of 343 BC and draw and then manipulate a
>>>>> boundary like you do in Photoshop. Maybe I could then put in some
>>>>> placemarks for specific events that then link to Wikipedia
>>>>> articles about
>>>>> them. Then when I'm done I could hit upload and see the changes on
>>>>> a master
>>>>> set of maps that anyone can work on. If it were that easy you
>>>>> could maybe
>>>>> get a lot of history buffs to do the work for free, a la Wikipedia.
>>>>> Teachers in particular might be interested because the end product
>>>>> could
>>>>> really help in teaching history.
>>>>>
>>>>> I've been reading the emails to try to figure out if something
>>>>> like this is
>>>>> in the works, but I admit, there's so much that's over my head
>>>>> that I just
>>>>> get lost. Does any of what I'm describing sound like anyone's plans?
>>>>>
>>>>> Thanks so much for reading this,
>>>>>
>>>>> Ed Dykhuizen
>>>>>
>>>>> (And I'm including my friend Joe on this -- hope you don't mind!)
>>>>
>>>>
>>>> _______________________________________________
>>>> Historic mailing list
>>>> [email protected]
>>>> http://lists.openstreetmap.org/listinfo/historic
>>>
>>
>>
>>
>>
>>------------------------------
>>
>>Message: 3
>>Date: Tue, 5 Mar 2013 23:13:26 -0400
>>From: Rob Warren <[email protected]>
>>To: [email protected]
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <[email protected]>
>>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>
>>I think we don't have choice with the dates tag or else we'll end up
>>with a monster database filled with unusable anachronisms. Without
>>going off the handle immediately, I like the idea of the API
>>validating the data with simple rules: "Must have dates set and/or
>>must have documentation".
>>
>>The nice thing about multiple front-ends / application / clients is
>>that we'll be able to enforce standardized tags for things a little
>>easier by having the application do it for the user directly.
>>
>>best,
>>rhw
>>
>>
>>On 4-Mar-13, at 10:02 PM, [email protected] wrote:
>>
>>> Message: 7
>>> Date: Mon, 4 Mar 2013 18:02:16 -0800
>>> From: Jeff Meyer <[email protected]>
>>> To: mick <[email protected]>
>>> Cc: [email protected]
>>> Subject: Re: [OHM] Historic places versus confidence
>>> Message-ID:
>>> <CAA1fFeyR1vvEOc=cjkw81n6x-j9va5lsq3d9h35g6xfwb2g...@mail.gmail.com>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Ref Mick's last comment - a couple of thoughts / questions:
>>>
>>> 1) We will have an opportunity to shape tagging policy a little more
>>> tightly than the greater OSM tagging canon. I'm looking forward to
>>> that.
>>> Not saying we'll get to the right answer immediately, but we could
>>> start
>>> somewhere & see how it works.
>>>
>>> 2) What do people think about eventually enforcing/strongly
>>> encouraging use
>>> of certain tags - e.g. date-related, source, anything else? I'm
>>> thinking of
>>> simple JOSM rules/validations looking for the presence of tags. We
>>> could
>>> also put some rules directly into the API...
>>>
>>> - Jeff
>>>
>>> On Mon, Mar 4, 2013 at 4:28 PM, mick <[email protected]> wrote:
>>>
>>>> On Mon, 4 Mar 2013 16:07:09 -0400
>>>> Rob Warren <[email protected]> wrote:
>>>>
>>>>>
>>>>> I'd like to get it to that point, especially in recording the
>>>>> changes
>>>> ...
>>>>>
>>>> I agree, we can never envisage the totality of uses for the data
>>>> once it
>>>> is there nor the tools that will be needed. A client/server
>>>> capability will
>>>> go a long way to meeting this challenge.
>>>>
>>>> To work effectively tagging will need to be far more consistent and
>>>> clearer than OSM currently allows.
>>>>
>>>> _______________________________________________
>>>> Historic mailing list
>>>> [email protected]
>>>> http://lists.openstreetmap.org/listinfo/historic
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Meyer
>>> Global World History Atlas
>>> www.gwhat.org
>>> [email protected]
>>> 206-676-2347
>>> <http://www.openstreetmap.org/user/jeffmeyer> osm: Open Historical Map
>>> (OHM)<http://wiki.openstreetmap.org/wiki/Open_Historical_Map>
>>> / my OSM user page <http://www.openstreetmap.org/user/jeffmeyer>
>>> t: @GWHAThistory <https://twitter.com/GWHAThistory>
>>> f: GWHAThistory <https://www.facebook.com/GWHAThistory>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstreetmap.org/pipermail/historic/attachments/20130304/60246d0e/attachment.html
>>> >
>>
>>
>>
>>
>>------------------------------
>>
>>Message: 4
>>Date: Wed, 6 Mar 2013 14:42:25 +1000
>>From: mick <[email protected]>
>>To: [email protected]
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <[email protected]>
>>Content-Type: text/plain; charset=US-ASCII
>>
>>On Tue, 5 Mar 2013 23:13:26 -0400
>>Rob Warren <[email protected]> wrote:
>>
>>>
>>> I think we don't have choice with the dates tag or else we'll end up
>>> with a monster database filled with unusable anachronisms. Without
>>> going off the handle immediately, I like the idea of the API
>>> validating the data with simple rules: "Must have dates set and/or
>>> must have documentation".
>>>
>>> The nice thing about multiple front-ends / application / clients is
>>> that we'll be able to enforce standardized tags for things a little
>>> easier by having the application do it for the user directly.
>>>
>>> best,
>>> rhw
>>>
>>One issue I have with "documentation" is the field length limits of GIS
>>packages. Maybe the documentation field could be a URL pointing to the actual
>>text.
>>
>>I use the OSM plug-in in QGIS to convert OSM to MapInfo or, to a lesser
>>extent, ESRI files. MapInfo has a maximum field length of 254 characters for
>>a text field, ESRI text fields are 80 characters. MapInfo also has a limited
>>number of fields (its less than 67, not sure how much less. You can still
>>open the file but only for READONLY access.
>>
>>I prefer to use MapInfo because:
>>the editing is much easier than QGIS.
>>versions before v8 can run in Linux under wine.
>>MapInfo uses a feature oriented model whereas ESRI is geometry oriented. E.G.
>>MapInfo can contain points, lines and areas in a single layer where ESRI
>>requires separate layers for each geometric type which I find confusing.
>>
>>mick
>>
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>Historic mailing list
>>[email protected]
>>http://lists.openstreetmap.org/listinfo/historic
>>
>>
>>End of Historic Digest, Vol 8, Issue 5
>>**************************************
>>
>
>_______________________________________________
>Historic mailing list
>[email protected]
>http://lists.openstreetmap.org/listinfo/historic
>
>
>
_______________________________________________
Historic mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/historic
