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= > [email protected]> > > 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
