[OHM] Historic Digest, Vol 8, Issue 5

Fri Mar 8 13:34:53 UTC 2013

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 <brad at pastmapper.com>
>To: historic at openstreetmap.org; sean.gillies at gmail.com 
>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, <historic-request at openstreetmap.org> wrote:
>
>
>>Message: 1
>>Date: Tue, 5 Mar 2013 09:21:02 -0700
>>From: Sean Gillies <sean.gillies at gmail.com>
>>To: Brad Thompson <brad at pastmapper.com>
>>Cc: historic at openstreetmap.org
>>Subject: Re: [OHM] Mapping what's on the ground and other good
>>        practices
>>Message-ID:
>>        <CAOodmJqOuWiTKavZG-SP2L7QWAey4MnSxHgFDwz2LEtYnfHoRg at 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 <brad at pastmapper.com> 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
>>> Historic at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/historic
>>>
>>
>>
>>
>>--
>>Sean Gillies
>>
>>
>>
>>------------------------------
>>
>>Message: 2
>>Date: Tue, 5 Mar 2013 23:05:09 -0400
>>From: Rob Warren <warren at muninn-project.org>
>>To: johnny0 <burritojustice at oram.com>
>>Cc: historic at openstreetmap.org, pettigrj at hotmail.com
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <5CDF54DF-9473-4DB0-9929-6BEB9073C4D5 at muninn-project.org>
>>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 <warren at muninn-project.org>
>>> 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, historic-request at openstreetmap.org wrote:
>>>>
>>>>> Message: 2
>>>>> Date: Thu, 28 Feb 2013 16:52:27 -0600
>>>>> From: Ed Dykhuizen <eddykhuizen at gmail.com>
>>>>> To: Burrito Justice <burritojustice at oram.com>
>>>>> Cc: "historic at openstreetmap.org" <historic at openstreetmap.org>,
>>>>> Joseph
>>>>>     Pettigrew <pettigrj at hotmail.com>
>>>>> Subject: Re: [OHM] [Historic] Historic Digest, Vol 7, Issue 9
>>>>> Message-ID:
>>>>>     <CAHDqN=8gEhHzJeazX6-s8RCu00uE0B-
>>>>> wdiqbqdZPnK9mYLDZbA at mail.gmail.com>
>>>>> 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
>>>> Historic at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/historic
>>>
>>
>>
>>
>>
>>------------------------------
>>
>>Message: 3
>>Date: Tue, 5 Mar 2013 23:13:26 -0400
>>From: Rob Warren <warren at muninn-project.org>
>>To: historic at openstreetmap.org
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <9682C71C-33D5-4B78-949F-93DAE4409823 at muninn-project.org>
>>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, historic-request at openstreetmap.org wrote:
>>
>>> Message: 7
>>> Date: Mon, 4 Mar 2013 18:02:16 -0800
>>> From: Jeff Meyer <jeff at gwhat.org>
>>> To: mick <bareman at tpg.com.au>
>>> Cc: historic at openstreetmap.org
>>> Subject: Re: [OHM] Historic places versus confidence
>>> Message-ID:
>>>       <CAA1fFeyR1vvEOc=CJKw81N6x-J9vA5Lsq3D9H35g6xFWB2gP-Q at 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 <bareman at tpg.com.au> wrote:
>>>
>>>> On Mon, 4 Mar 2013 16:07:09 -0400
>>>> Rob Warren <warren at muninn-project.org> 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
>>>> Historic at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/historic
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Meyer
>>> Global World History Atlas
>>> www.gwhat.org
>>> jeff at gwhat.org
>>> 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 <bareman at tpg.com.au>
>>To: historic at openstreetmap.org
>>Subject: Re: [OHM] Historic places versus confidence
>>Message-ID: <20130306144225.3d871ffa at cave.bareclan>
>>Content-Type: text/plain; charset=US-ASCII
>>
>>On Tue, 5 Mar 2013 23:13:26 -0400
>>Rob Warren <warren at muninn-project.org> 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
>>Historic at openstreetmap.org
>>http://lists.openstreetmap.org/listinfo/historic
>>
>>
>>End of Historic Digest, Vol 8, Issue 5
>>**************************************
>>
>
>_______________________________________________
>Historic mailing list
>Historic at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/historic
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20130308/71a2df8d/attachment-0001.html>