[OHM] Historic Digest, Vol 8, Issue 5

Fri Mar 8 01:17:07 UTC 2013

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
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20130307/ba6cac7e/attachment-0001.html>