Re: [talk-au] The trouble with tracing
Nick Hocking writes: > Good tracing is quite helpful in the final definition of a way, > > Bad tracing is really bad - it takes a multiple of the original effort to correct it. > > Ok - having resolved that, I believe that the difference between good mapping and bad > mapping will be absolutely correlated to the number of "one way" errors and "turn restriction" errors. > > > In order to say that a route from Street A to Street B is possible you must have actually done it yourself. > It's not good enough to have just passed along a nearby cross street, to snaffle the street sign name. > > For entitys that need to be routable, you *must* actually travel that route to verify it's correctness. > > PS - you can't read a "No Right Turn" sign from a satellite and you're not allowed to use Google Steet Views. Hi Nick, I don't have a GPS yet, so I'm a tracer. I think I've been fairly productive in OSM (see http://bluemm.blogspot.com/2008/10/first-update-on-mapping-openstreetmap.html on my workflow practises). Recently, I haven't been doing much tracing, preferring to go out there and take notes down on POI's/surfaces/stop signs/postboxes etc. on a printed out map. It has been mentioned on the Talk mailing list, but we probably need some kind of survey_visited=2009-01-15 tag to indicate when someone last went down the road and verified all the tags/POI's. I am kind of doing it now by using source:name=survey but that is only for when I have seen the street sign at intersections. Some way of indicating that I went down this road and noted/verified all the OSM data would be great. Also, accurate routing has to be a goal, but it's a lot of effort needed to get there. Obviously a printable map will come before that, and probably is more important for OSM to win hearts & minds. Tracing vs GPS tracks from a car doing 60kmh+ will get us nice maps, but not useful routing data. I think of it as stages or levels of completeness. BlueMM ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, 05 Feb 2009 17:18:53 +1030 Jack Burton wrote: > But I'm still not a fan of relations for suburb boundaries - even more > so, now that we know that the authoritative set for Australia (the ABS > data) is organised as a set of polygons (one for each suburb), since > we'll presumably want to continue using this dataset for updates (e.g. > when new suburbs appear, or old ones are split > up/consolidated/renamed/etc.). This could be accomplished really > easily if each item of ABS data was tagged with a source_ref:ABS (or > whatever) set to corresponding object id from the ABS dataset (I'm > assuming it uses such things - most large datasets do). And as soon as we edit that data in any way, such as you yourself suggest doing lower down in your reply, then updates from ABS are only ever going to be able to be imported as diffs - a straight 'update to these values' will break any adjusted edges and move other ways around. This will require extensive processing and either option can be handled at that time. You also assume the ABS is actually going to be (a) recently up to date (b) accurate, I'm not holding my breath on either, so blindly syncing with any changes they make is not necessarily wise. > It still seems to me that the simplest possible set of data to define > a suburb is the location of its town centre (a single node) and the > outline of its boundary (a single way). [And we already have most of > the nodes for NSW towns/suburbs in the OSM dataset, from another bulk > import of government data - adding suburb areas from the ABS data > would give us complete definitions for NSW, and the hard part done > already for other states] I isolation this makes sense, when included with other features such as roads etc it makes more sense that if a suburb boundary runs down a road that road is some how flagged as part of the boundary. Stand alone areas make extra work correlating that kind of data. > Also, consider the case of a user downloading a rectangular section > from OSM (since I'd imagine most of us do that, rather than deal with > enormous planet or country files), where a suburb boundary intersects > the boundary of the rectangle downloaded: > > If we use the single way method, the OSM API will give the user the > entire suburb boundary, even the bits that are outside the rectangle - > so every suburb that has any part of itself within the rectangle will > have its boundary fully defined within the user's osm file. > > If we use the relation method, only those segments of the boundary > which have nodes within the rectangle will be supplied - leaving some > suburbs with incomplete boundaries in the user's osm file. If the user doing the download is not prepared to handle the relation issue with respect to boundaries they will probably encounter far greater problems that just suburb boundaries. Multi-polygon relations for example will suffer from exactly the same problem. The issue is that the down-loader needs to be aware of the data structure and not make the data structure adjust to handle his in-competencies. For example in JOSM it's a matter of a 3 clicks to request all the ways of boundary. There are already issues of ways with too many nodes causing downloading problems for the OSM servers, a single area for a whole rural suburb (or one of the bigger boundaries like a council) is easily going to exceed reasonable limits of way length, and unlike a way where you have to download the entire way every time it's viewed, with relations you can choose to download only the relevant parts, and the whole lot if you need it. Should you happen to not have your download's bounding box cross any of the suburb boundaries with either method you may just end up with no suburb data at all anyway. Assuming you can rely on suburb data from a small are download is a little naive. > The only situation I can think of where a relation would be necessary > for a suburb boundary would be when one suburb exists wholly within > the boundaries of another suburb - but we already have the > multipolygon relation for that (and I can't think of a single Aussie > example of this off the top of my head - in fact, the only one I can > think of globally is Vatican City being wholly within Rome - although > we do have a similar situation for state borders with NSW/ACT). It's also able to be handled by the boundary relation with enclaves and exclaves which are designed for exactly this reason. ACT/NSW being a prime example of exactly that. Interestingly there is now support in multi-polygon relations for outer and inner ways to be broken into multiple ways (mapnik and josm already handle them properly) rather than being single areas, further indicating that stacked ways is not considered the ideal solution to these problems. > This can be done either way - since with the one closed way per suburb > method, the nodes along shared portions of boundaries should be common > anyway: a mapper fixing an incorrect bound
Re: [talk-au] Suburb boundaries
On Thu, 5 Feb 2009 18:30:58 +1100 Franc Carter wrote: > I have added an entry to the data catalogue at > >http://wiki.openstreetmap.org/wiki/Import/Catalogue#One-Time_Imports > > and the beginnings of page about the import at > Post codes and Electorals Boundaries map up nicely to a boundary relation (especially given post codes align with suburb boundaries as far as I know), however they will really test the limits of the area model since they will be so much larger, and have many more points. I was ponder about electoral boundaries a while back, and realised they probably fall just about the 'council' level and should therefor have a admin_level of 5. But lets worry about the suburbs first ;) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
I have added an entry to the data catalogue at http://wiki.openstreetmap.org/wiki/Import/Catalogue#One-Time_Imports and the beginnings of page about the import at http://wiki.openstreetmap.org/wiki/Import/Catalogue/ABS_Data cheers On Thu, Feb 5, 2009 at 4:48 PM, Franc Carter wrote: > > All confirmed - let the fun begin. > > cheers > > > On Thu, Feb 5, 2009 at 2:26 PM, Franc Carter wrote: > >> >> I just had a conversation with a really helpful person at the ABS. >> >> She indicated that the ABS is taking a view of the data that is very >> similar/compatible >> with (at least my understanding) the view that OpenStreetMap is taking >> towards the >> data. >> >> Specifically she indicated that the ABS was not specifically concerned >> that attribution was >> done in a specific manner, just that the attribution was able to be found. >> She will put >> something in an email so that we have an official statement. >> >> So, it looks like we may well have a some valuable data to add, which is >> good because >> I already spent a couple of hours working out hot to import it ;-) >> >> There are two issues that I have come across with converting to osm:- >> >>1. What way do we want to represent the data, e.g closed ways or >> relations consisting >>of borders - something else ? >> >>2. The more technical problem that the boundaries are defined fairly >> precisely (or more accurately >>there are lots of points defining the boundaries). So the .osm file >> is very large - so eyeballing >>it in josm is not going to work. >> >> So I'm interested in people's suggestions of how we want to represent the >> data and on methods we can >> use to sanity check the data before we upload it. >> >> cheers >> >> >> >> On Sat, Jan 31, 2009 at 6:23 AM, James Churchill wrote: >> >>> Franc Carter writes: >>> >>> > While putting together an email for this I came across an issue. >>> > Currently OSM is Creative Commons licensed which looks pretty >>> compatible with >>> > their license (ignoring the practicalities of attribution). However the >>> license > is being discussed at the moment and may well soon change >>> and/or split. >>> > Should I wait until the license issue gets 'sorted' ? >>> >>> I don't see a problem - the CC license the data is under only requires >>> attribution, it doesn't restrict what the license of the derivative work >>> is. And >>> as OSM is looking for a license that (and I quote) "needs to give our >>> database >>> the same three basic licensing elements (freely copiable; share-alike; >>> attribution required) as it has at present" there's little worry of OSM >>> becoming >>> incompatible. >>> >>> At least, the matter shouldn't delay inquiries :) >>> >>> - James >>> >>> >>> >>> ___ >>> Talk-au mailing list >>> Talk-au@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-au >>> >> >> >> >> -- >> Franc >> > > > > -- > Franc > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, 05 Feb 2009 16:29:39 +1030 Jack Burton wrote: > >1. What way do we want to represent the data, e.g closed ways or > > relations consisting of borders - something else ? > > Closed ways (areas) - as that's how ABS define them, so it will make > merging updated ABS data into the OSM Australia dataset (each time ABS > update their dataset, which is presumably quite regularly) > significantly easier. This isn't really relevant. Given the amount of data involved an automated process will have to be developed to bring it all in, so this process can just be re-utilised on any update. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
The ideas I have been fiddling with over the last couple of hours actually work well for both the close-way and relation approach with just a small bit of code at the output stage. So I'm going to delay making a decision until more discussion and thought goes in to it. The idea of chopping it up and making it available is a good one. I have the weird sort of brain that can spot anomalies in large amounts of data so scanning it all seemed 'natural' to me(1) But you are right, that would be nowhere near sufficient. cheers (1) I did actually notice that there are problems with islands that are in the same suburb as part o the mainland cheers On Thu, Feb 5, 2009 at 4:59 PM, Jack Burton wrote: > On Thu, 2009-02-05 at 14:26 +1100, Franc Carter wrote: > > I just had a conversation with a really helpful person at the ABS. > > > > She indicated that the ABS is taking a view of the data that is very > > similar/compatible with (at least my understanding) the view that > > OpenStreetMap is taking towards the data. > > > > Specifically she indicated that the ABS was not specifically concerned > > that attribution was done in a specific manner, just that the > > attribution was able to be found. She will put something in an email > > so that we have an official statement. > > > > So, it looks like we may well have a some valuable data to add, which > > is good because I already spent a couple of hours working out hot to > > import it ;-) > > That's great news! > > > There are two issues that I have come across with converting to osm:- > > > >1. What way do we want to represent the data, e.g closed ways or > > relations consisting of borders - something else ? > > Closed ways (areas) - as that's how ABS define them, so it will make > merging updated ABS data into the OSM Australia dataset (each time ABS > update their dataset, which is presumably quite regularly) significantly > easier. > > >2. The more technical problem that the boundaries are defined > > fairly precisely (or more accurately there are lots of points defining > > the boundaries). So the .osm file is very large - so eyeballing it in > > josm is not going to work. > > So I'm interested in people's suggestions of how we want to represent > > the data and on methods we can use to sanity check the data before we > > upload it. > > Might I suggest that trying to verify the entire set of Australian > suburb boundaries by inspection would seem an impossible task anyway - > wouldn't be able to "see the wood for the trees". > > For sanity checking purposes, why not split the generated OSM file up > into a bunch of small, managable areas - then pick one you know really > well and check it out in josm. If you're concerned that areas you don't > know well might need checking too, perhaps put the whole lot on a > webserver somewhere and ask on the list for other mappers to download & > check out areas they know well too before doing the bulk upload to OSM? > > Regards, > > > Jack. > > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, 2009-02-05 at 14:26 +1100, Franc Carter wrote: > I just had a conversation with a really helpful person at the ABS. > > She indicated that the ABS is taking a view of the data that is very > similar/compatible with (at least my understanding) the view that > OpenStreetMap is taking towards the data. > > Specifically she indicated that the ABS was not specifically concerned > that attribution was done in a specific manner, just that the > attribution was able to be found. She will put something in an email > so that we have an official statement. > > So, it looks like we may well have a some valuable data to add, which > is good because I already spent a couple of hours working out hot to > import it ;-) That's great news! > There are two issues that I have come across with converting to osm:- > >1. What way do we want to represent the data, e.g closed ways or > relations consisting of borders - something else ? Closed ways (areas) - as that's how ABS define them, so it will make merging updated ABS data into the OSM Australia dataset (each time ABS update their dataset, which is presumably quite regularly) significantly easier. >2. The more technical problem that the boundaries are defined > fairly precisely (or more accurately there are lots of points defining > the boundaries). So the .osm file is very large - so eyeballing it in > josm is not going to work. > So I'm interested in people's suggestions of how we want to represent > the data and on methods we can use to sanity check the data before we > upload it. Might I suggest that trying to verify the entire set of Australian suburb boundaries by inspection would seem an impossible task anyway - wouldn't be able to "see the wood for the trees". For sanity checking purposes, why not split the generated OSM file up into a bunch of small, managable areas - then pick one you know really well and check it out in josm. If you're concerned that areas you don't know well might need checking too, perhaps put the whole lot on a webserver somewhere and ask on the list for other mappers to download & check out areas they know well too before doing the bulk upload to OSM? Regards, Jack. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
All confirmed - let the fun begin. cheers On Thu, Feb 5, 2009 at 2:26 PM, Franc Carter wrote: > > I just had a conversation with a really helpful person at the ABS. > > She indicated that the ABS is taking a view of the data that is very > similar/compatible > with (at least my understanding) the view that OpenStreetMap is taking > towards the > data. > > Specifically she indicated that the ABS was not specifically concerned that > attribution was > done in a specific manner, just that the attribution was able to be found. > She will put > something in an email so that we have an official statement. > > So, it looks like we may well have a some valuable data to add, which is > good because > I already spent a couple of hours working out hot to import it ;-) > > There are two issues that I have come across with converting to osm:- > >1. What way do we want to represent the data, e.g closed ways or > relations consisting >of borders - something else ? > >2. The more technical problem that the boundaries are defined fairly > precisely (or more accurately >there are lots of points defining the boundaries). So the .osm file > is very large - so eyeballing >it in josm is not going to work. > > So I'm interested in people's suggestions of how we want to represent the > data and on methods we can > use to sanity check the data before we upload it. > > cheers > > > > On Sat, Jan 31, 2009 at 6:23 AM, James Churchill wrote: > >> Franc Carter writes: >> >> > While putting together an email for this I came across an issue. >> > Currently OSM is Creative Commons licensed which looks pretty compatible >> with >> > their license (ignoring the practicalities of attribution). However the >> license > is being discussed at the moment and may well soon change and/or >> split. >> > Should I wait until the license issue gets 'sorted' ? >> >> I don't see a problem - the CC license the data is under only requires >> attribution, it doesn't restrict what the license of the derivative work >> is. And >> as OSM is looking for a license that (and I quote) "needs to give our >> database >> the same three basic licensing elements (freely copiable; share-alike; >> attribution required) as it has at present" there's little worry of OSM >> becoming >> incompatible. >> >> At least, the matter shouldn't delay inquiries :) >> >> - James >> >> >> >> ___ >> Talk-au mailing list >> Talk-au@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-au >> > > > > -- > Franc > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
I did some basic sanity checking in my quick script and there is a lot of points that are doubled up (i.e have the same lat/lon) which indicates that the data does form sensible/consistent boundaries. My 'intuition' is that the shape=>boundary problem is solvable, I'll just need to put some thought in to it - actually as I write this, I think I know the approach ;-) Solving this will also help with one of the other issues that I came across, which was 'curve simplification'. There are vast numbers of redundant points in many of the boundaries where they make no difference to the shape. However doing curve simplification on closed shapes with shared boundaries results in different points being removed from the two boundaries. Small samples sounds like a good first approach - I have lots of gps tracks for the area I live in that were taken with a roof mounted aerial, so I have a reasonably high level of confidence in them cheers On Thu, Feb 5, 2009 at 4:02 PM, Darrin Smith wrote: > On Thu, 5 Feb 2009 15:52:43 +1100 > Franc Carter wrote: > > > From a 'philosophical point of view', I tend to agree that suburbs > > are made of > > a set of boundaries between adjacent areas. This was not how I did it > > in my first (very quick) attempt ;-( > > An advantage of having to sort out the legal issue means you get a bit > of time to fiddle around trying out options before you get the full > a-ok and import it ;) > > > The data is in shapefiles that define each suburb boundary > > individually, so I'll have a think about how to extract out the > > individual borders (suggestions > > welcome) > > Hmm, so there's no real surety that 2 adjacent suburbs even share the > same boundary? Perhaps then the single area option might have some > merit from a 'getting the data in there' point of view or we write > a convoluted script to correlate things... > > > One question about aligning them that springs to mind is 'what should > > we align' - I wonder if the accuracy of the data is better than the > > average accuracy > > of a gps or yahoo imagery. > > That's a tricky question because it might be more 'accurate' because it > might measure to an exact positional definition but is that useful or > relevant to the OSM structure whereby a boundary down the middle of the > road is more conceptually accurate > > Guess we have to get a small sample of the data into a city somewhere > where we have plenty of GPS as a trial run (once we have the full ok). > and see how it correlates to reality. > > GPS + Yahoo never correlate enough (at least in SA) to make it possible > for both to be relevant :) > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, 5 Feb 2009 15:52:43 +1100 Franc Carter wrote: > From a 'philosophical point of view', I tend to agree that suburbs > are made of > a set of boundaries between adjacent areas. This was not how I did it > in my first (very quick) attempt ;-( An advantage of having to sort out the legal issue means you get a bit of time to fiddle around trying out options before you get the full a-ok and import it ;) > The data is in shapefiles that define each suburb boundary > individually, so I'll have a think about how to extract out the > individual borders (suggestions > welcome) Hmm, so there's no real surety that 2 adjacent suburbs even share the same boundary? Perhaps then the single area option might have some merit from a 'getting the data in there' point of view or we write a convoluted script to correlate things... > One question about aligning them that springs to mind is 'what should > we align' - I wonder if the accuracy of the data is better than the > average accuracy > of a gps or yahoo imagery. That's a tricky question because it might be more 'accurate' because it might measure to an exact positional definition but is that useful or relevant to the OSM structure whereby a boundary down the middle of the road is more conceptually accurate Guess we have to get a small sample of the data into a city somewhere where we have plenty of GPS as a trial run (once we have the full ok). and see how it correlates to reality. GPS + Yahoo never correlate enough (at least in SA) to make it possible for both to be relevant :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
>From a 'philosophical point of view', I tend to agree that suburbs are made of a set of boundaries between adjacent areas. This was not how I did it in my first (very quick) attempt ;-( The data is in shapefiles that define each suburb boundary individually, so I'll have a think about how to extract out the individual borders (suggestions welcome) One question about aligning them that springs to mind is 'what should we align' - I wonder if the accuracy of the data is better than the average accuracy of a gps or yahoo imagery. cheers On Thu, Feb 5, 2009 at 3:39 PM, Darrin Smith wrote: > On Thu, 5 Feb 2009 14:26:13 +1100 > Franc Carter wrote: > > > There are two issues that I have come across with converting to osm:- > > > >1. What way do we want to represent the data, e.g closed ways or > > relations consisting > >of borders - something else ? > > I'd personally prefer border relations. But given Franc and I seem > to be the only significant creators of relations in .au anyway (A > search of the australia.osm reveals we're the only two with > 100 > relations) I don't think the majority of regular osm mappers have got > relations yet. > > However I think relations are the way data like this is going in OSM. > > >2. The more technical problem that the boundaries are defined > > fairly precisely (or more accurately > >there are lots of points defining the boundaries). So the .osm > > file is very large - so eyeballing > >it in josm is not going to work. > > > > So I'm interested in people's suggestions of how we want to represent > > the data and on methods we can > > use to sanity check the data before we upload it. > > Lots of the cases are along roads/rivers/railways I imagine to > make them align with what we actually have on the map, lots of review > is going to have to happen once it's actually in the map anyway. > > Given nearly all suburb boundaries are multiples (one suburb on each > side). I'd think 1 way for a common boundary between 2 suburbs and > joining up all those ways for each suburb in a relation would be the > way to go. Then people can review them in areas where there's existing > data and re-align them down the middle of roads they run along or > remove the chunks than overlap single ways and add those ways to the > boundary. > > > > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, 5 Feb 2009 14:26:13 +1100 Franc Carter wrote: > There are two issues that I have come across with converting to osm:- > >1. What way do we want to represent the data, e.g closed ways or > relations consisting >of borders - something else ? I'd personally prefer border relations. But given Franc and I seem to be the only significant creators of relations in .au anyway (A search of the australia.osm reveals we're the only two with > 100 relations) I don't think the majority of regular osm mappers have got relations yet. However I think relations are the way data like this is going in OSM. >2. The more technical problem that the boundaries are defined > fairly precisely (or more accurately >there are lots of points defining the boundaries). So the .osm > file is very large - so eyeballing >it in josm is not going to work. > > So I'm interested in people's suggestions of how we want to represent > the data and on methods we can > use to sanity check the data before we upload it. Lots of the cases are along roads/rivers/railways I imagine to make them align with what we actually have on the map, lots of review is going to have to happen once it's actually in the map anyway. Given nearly all suburb boundaries are multiples (one suburb on each side). I'd think 1 way for a common boundary between 2 suburbs and joining up all those ways for each suburb in a relation would be the way to go. Then people can review them in areas where there's existing data and re-align them down the middle of roads they run along or remove the chunks than overlap single ways and add those ways to the boundary. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] National Park & Marine Park boundaries
Hi all, I'm new'ish to OSM and have been mapping the largely unmapped area around me. We've got lots of undefined (in the OSM sense) National Parks nearby and was wondering if there'd been any progress on getting park boundary data. Note yahoo imagery around me is of low quality so difficult to do any accurate tracing. Ta, jeffp_oz [talk-au] National Park & Marine Park boundariesLiz edodd at billiau.net Wed Dec 17 10:58:04 GMT 2008 * Previous message: [talk-au] National Park & Marine Park boundaries * Next message: [talk-au] National Park & Marine Park boundaries * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Wed, 17 Dec 2008, Matt White wrote: > How are people mapping National Park (or state forest or other > government mandated areas)? It seems that in a lot of cases, there is no > way of actually doing an on the ground survey - a lot of the boundaries > aren't marked, the areas can be massively inaccessible etc. > > Add to that things like marine park boundaries, or no fishing areas > which are often defined on marine maps as just a set of GPS locations > (and there is obviously no way of physically mapping those areas), and > it seems there are a lot of things that we have to rely on getting the > data from other sources for.(I include marine park/no fishing areas as > my partners father asked about it - I see no good reason why such > features couldn't be added to OSM) > > Question is: is it legit to use park/forest boundaries taken from > government sources? If not, how on earth are we going to solve this > little problem? > > Matt > My significant other is trying to obtain national park data as defined lat and long co-ordinates. I think that putting points in on co-ordinates which are defined does not infringe anyone's copyright.___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
I just had a conversation with a really helpful person at the ABS. She indicated that the ABS is taking a view of the data that is very similar/compatible with (at least my understanding) the view that OpenStreetMap is taking towards the data. Specifically she indicated that the ABS was not specifically concerned that attribution was done in a specific manner, just that the attribution was able to be found. She will put something in an email so that we have an official statement. So, it looks like we may well have a some valuable data to add, which is good because I already spent a couple of hours working out hot to import it ;-) There are two issues that I have come across with converting to osm:- 1. What way do we want to represent the data, e.g closed ways or relations consisting of borders - something else ? 2. The more technical problem that the boundaries are defined fairly precisely (or more accurately there are lots of points defining the boundaries). So the .osm file is very large - so eyeballing it in josm is not going to work. So I'm interested in people's suggestions of how we want to represent the data and on methods we can use to sanity check the data before we upload it. cheers On Sat, Jan 31, 2009 at 6:23 AM, James Churchill wrote: > Franc Carter writes: > > > While putting together an email for this I came across an issue. > > Currently OSM is Creative Commons licensed which looks pretty compatible > with > > their license (ignoring the practicalities of attribution). However the > license > is being discussed at the moment and may well soon change and/or > split. > > Should I wait until the license issue gets 'sorted' ? > > I don't see a problem - the CC license the data is under only requires > attribution, it doesn't restrict what the license of the derivative work > is. And > as OSM is looking for a license that (and I quote) "needs to give our > database > the same three basic licensing elements (freely copiable; share-alike; > attribution required) as it has at present" there's little worry of OSM > becoming > incompatible. > > At least, the matter shouldn't delay inquiries :) > > - James > > > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
