Re: [Talk-ca] Ontario 040P
The address range fields are shown in BC, but just not filled in like they are in Alberta. ... It isnt being used because we havent found a way to use it yet. Hopefully, when i learn how to use geobase2osm, i'll have the answer. On 6/20/09, Michel Gilbert wrote: > Hi Sam, > > I do not want to put you on a false track but I think the address ranges > are > not part of Canvev. I hope Guy will be able to confirm or please you. > > Cheers, > > Michel > > 2009/6/20 Sam Vekemans > >> Would you know when it will be available in the CanVec data? >> >> Has anyone thought of how we can make use of the geobase address range >> data? >> Does anyone want an .osm file to be made that just has the 4 address >> range fields (and the proper source tags) made as i go through with >> canvec2osm? >> >> Cheers, >> Sam >> >> >> On 6/18/09, Bergeron, Guy wrote: >> > Just a heads up that the next NRN release for Ontario, schedule for >> > this >> > summer (around August), will include street names and address ranges >> > from closest to source NRN providers. >> > >> > Guy >> > >> > -Original Message- >> > From: talk-ca-boun...@openstreetmap.org >> > [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Adam Glauser >> > Sent: 16 juin 2009 13:10 >> > To: talk-ca@openstreetmap.org >> > Subject: Re: [Talk-ca] Ontario 040P >> > >> > I've found (and since corrected) a couple more false-positive matches. >> > >> > Ways 35518380 was name="Old Oak Place", statscan:rbuid=3357619. These >> > tags should actually have been applied to way 35521248. The correct >> > tags for the first way are name="Aspenwood Place", >> > statscan:rbuid=3357613. >> > >> > Way 35502496 was name="Willow Wood Drive",statscan:rbuid=3357623. >> > Should be name="Woodrow Place",statscan:rbuid=3357623. This is tricky >> > in part due to one Statscan feature corresponding to two different >> > Geobase features (the entrance to the cul-de-sac and the >> > circle-with-middle-barrier part). >> > >> > I'll continue to report these unless I hear otherwise - I'm still new >> > here, if this is just noise please let me know. >> > >> > Also, thanks to Steve's pointers about OpenJUMP and the StatsCan road >> > name data, I've given names to a bunch of ways that Roadmatcher >> > couldn't >> > >> > resolve, along with their StatsCan RB_UIDs, using a combination of the >> > .shp file from the StatsCan website and local knowledge of the layout >> > of >> > >> > the roads. >> > >> > >> > ___ >> > Talk-ca mailing list >> > Talk-ca@openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-ca >> > >> > ___ >> > Talk-ca mailing list >> > Talk-ca@openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-ca >> > >> >> >> -- >> Twitter: @Acrosscanada >> Facebook: http://www.facebook.com/sam.vekemans >> >> ___ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-ca >> > > > > -- > Michel Gilbert > -- Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ontario 040P
Hi Sam, I do not want to put you on a false track but I think the address ranges are not part of Canvev. I hope Guy will be able to confirm or please you. Cheers, Michel 2009/6/20 Sam Vekemans > Would you know when it will be available in the CanVec data? > > Has anyone thought of how we can make use of the geobase address range > data? > Does anyone want an .osm file to be made that just has the 4 address > range fields (and the proper source tags) made as i go through with > canvec2osm? > > Cheers, > Sam > > > On 6/18/09, Bergeron, Guy wrote: > > Just a heads up that the next NRN release for Ontario, schedule for this > > summer (around August), will include street names and address ranges > > from closest to source NRN providers. > > > > Guy > > > > -Original Message- > > From: talk-ca-boun...@openstreetmap.org > > [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Adam Glauser > > Sent: 16 juin 2009 13:10 > > To: talk-ca@openstreetmap.org > > Subject: Re: [Talk-ca] Ontario 040P > > > > I've found (and since corrected) a couple more false-positive matches. > > > > Ways 35518380 was name="Old Oak Place", statscan:rbuid=3357619. These > > tags should actually have been applied to way 35521248. The correct > > tags for the first way are name="Aspenwood Place", > > statscan:rbuid=3357613. > > > > Way 35502496 was name="Willow Wood Drive",statscan:rbuid=3357623. > > Should be name="Woodrow Place",statscan:rbuid=3357623. This is tricky > > in part due to one Statscan feature corresponding to two different > > Geobase features (the entrance to the cul-de-sac and the > > circle-with-middle-barrier part). > > > > I'll continue to report these unless I hear otherwise - I'm still new > > here, if this is just noise please let me know. > > > > Also, thanks to Steve's pointers about OpenJUMP and the StatsCan road > > name data, I've given names to a bunch of ways that Roadmatcher couldn't > > > > resolve, along with their StatsCan RB_UIDs, using a combination of the > > .shp file from the StatsCan website and local knowledge of the layout of > > > > the roads. > > > > > > ___ > > Talk-ca mailing list > > Talk-ca@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-ca > > > > ___ > > Talk-ca mailing list > > Talk-ca@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-ca > > > > > -- > Twitter: @Acrosscanada > Facebook: http://www.facebook.com/sam.vekemans > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ontario 040P
Would you know when it will be available in the CanVec data? Has anyone thought of how we can make use of the geobase address range data? Does anyone want an .osm file to be made that just has the 4 address range fields (and the proper source tags) made as i go through with canvec2osm? Cheers, Sam On 6/18/09, Bergeron, Guy wrote: > Just a heads up that the next NRN release for Ontario, schedule for this > summer (around August), will include street names and address ranges > from closest to source NRN providers. > > Guy > > -Original Message- > From: talk-ca-boun...@openstreetmap.org > [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Adam Glauser > Sent: 16 juin 2009 13:10 > To: talk-ca@openstreetmap.org > Subject: Re: [Talk-ca] Ontario 040P > > I've found (and since corrected) a couple more false-positive matches. > > Ways 35518380 was name="Old Oak Place", statscan:rbuid=3357619. These > tags should actually have been applied to way 35521248. The correct > tags for the first way are name="Aspenwood Place", > statscan:rbuid=3357613. > > Way 35502496 was name="Willow Wood Drive",statscan:rbuid=3357623. > Should be name="Woodrow Place",statscan:rbuid=3357623. This is tricky > in part due to one Statscan feature corresponding to two different > Geobase features (the entrance to the cul-de-sac and the > circle-with-middle-barrier part). > > I'll continue to report these unless I hear otherwise - I'm still new > here, if this is just noise please let me know. > > Also, thanks to Steve's pointers about OpenJUMP and the StatsCan road > name data, I've given names to a bunch of ways that Roadmatcher couldn't > > resolve, along with their StatsCan RB_UIDs, using a combination of the > .shp file from the StatsCan website and local knowledge of the layout of > > the roads. > > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > -- Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
2009/6/17 Sam Vekemans : > Answered below, > > Twitter: @Acrosscanada > Facebook: http://www.facebook.com/sam.vekemans > > > On Wed, Jun 17, 2009 at 4:57 AM, "Marc Schütz" wrote: >> >> > I think the definitions really don't belong in the the data -- perhaps >> > if you want to see them, your browser should look them up in some >> > table rather than load from the data. >> >> +1 >> >> It should be sufficient to keep the canvec:UUID, source and attribution >> tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we >> would need most of the others. If someone is really interested in them, they >> can look them up in Canvec using the UUID. > > Actually, its not that easy to look up a source with the uuid from CanVec > data. > They would need to open up the shp files and sift through the data. > Unfortunately the canvec data isn't organized to that extreem on their > website. You don't need to look it up in the shp files, you can have it in a huge xml file or somewhere else because it's a trivial 1:1 conversion. The point is that the definition of what is a school (not the particular school to which the tag is attached) belongs in an encyclopaedia, not in a database of geographic data. The school object on the map is already fully defined by "amenity=school", now, if you want to interpret this you need to look it up in the Map_Features page or an encyclopaedia or in 99% cases from your prior knowledge. > The purpose of keeping the uuid is that it might be used during > the conversion process to compare old/new canvec data. Other than that, the > "source" tag is really the only one that is technically needed. > > > Arguments to keep all original tags as available. > > When importing large amounts of data, not only are we importing the data, > but also opening the door to all of the users of that data, who now have a > 2nd choice of where to extract the data (cloudmade provides shp files of OSM > data) > So now, users of geogratis data, can turn to OSM, where they can now see the > value of working WITH the data. For example, a federal parks manager, who > would turn to geogratis to get a basemap, can now use OSM, as the map is > more accurate. > However, because government is a stickler for 'official source' we can > provide the source tags, that anyone can go to geogratis and varify the > detail. > > This is a fair trade off, as not only am i copying the data, i am providing > an accurate 'carbon' copy of the origional source. > > In order to be 'sync' with the import data, it all needs to be there. (All > or none?) > > I think this is a fare tradeoff, as it lets us have are cake, eat it, AND > also share it with more types of data users. (where a certain other map, > doesnt do this) ... (ie if BC Parks decides do donate their 'official' > property boundaries) they too could include their back-end cross referencing > system, and ALSO include osm standard tags) > > Arguments against: > -This is OpenSTREETMap where we only provide ways with names, and make > relations and add things that end users want. > > But, an end-user can also be a city planner who is thinking of sharing all > there origional survay data, and property boundary information. Provided > they can also include lot numbers, and official property easment. > > If there is an unlimited number of tags alloud, why not keep them? > > If i remove SOME and not ALL, where do we draw this line in the sand? > > I think we need to make it clear on a global level, exactly WHAT should be > included or omited with an import. (any builk import for that matter) It's quite clear, I think: - include things that carry some new information (e.g. amenity=school) - omit things that are redundant, because they can be inferred from other tags on the object or from an external, non-geographic database (the definition of a building, school, road) There's a 1:1 correspondence between the value of amenity= and the value of canvec:value_definition= so one of them should be removed. There's a 1:1 correspondence between the value of canvec:entity= and the value of canvec:entity_definition= so one of them should be removed. For example, let's say you're making a database of large prime numbers. For each entry you could store the prime number N, some kind of proof of why it's a prime or a method of deriving the number, the name of the discoverer, but not: - the definition of a prime number (redundant), - N+1 (redundant), - N^2 (redundant), > > If you dont like it because it looks like 'clutter', but infact its useful. > .. i dont know if thats a strong argument. > > Perhaps I think we need to find a former Geogratis user, who will now be > using OSM. And find out just how useful there tags are. (as im not one, my > voice is rather quite) > > Right now the evedence to keep all the tags is not that great. ... > > The process of removing these tags is not small. So a definate answer > should be found before i continue with more importing :) > > >
Re: [Talk-ca] [OpenStreetMap] geobase:acrosscanadatrails sent you a new message
What u have is great! It was only a few nodes with no source tags, which is why i wondered. You might want to create a wiki page for it, and a chart indicating all the tags your using. It looks like the tag format is right, but because its a bulk import, it needs to be added to the 'potential data sources' list. -and also have time for community feedback. Let me know when u have vancouver island/ bc loaded, will be great to see. :) Cheers, Sam On 6/16/09, Daniel Patterson wrote: > Hi Sam, > > I have to admit, I probably haven't been a good netzien as I could have > been with this import. I haven't sent any messages to talk-ca (I didn't > realise it existed until you mentioned it, I've joined the list now). > > First, a bit of background. I work for TRAFx Research, a small > electronics company in Canmore, AB. We make trail and vehicle counters > that > are primarily used by parks services of various sorts (Parks Canada is one > of our largest customers). > > We have a web-based data analysis tool that we use OSM to map out counter > locations with. Given that most of our customers are located in > parks/recreational areas, we would like to see nice data on the maps in > regions where our customers are located. A bit of research revealed the > Atlas of Canada data for national protected areas on GeoGratis, so we > thought we'd go ahead and do the work of importing it as a start. > > I'm fairly new to much of OSM stuff, so any hints as to how to better get > along with everyone would be appreciated. > > For the imports I've done so far (although I'm not sure if I've got them > totally correct), I've tried to keep as much meta-data intact as possible > from the SHP files that GeoGratis supplies. Here's a sample of the tags > I've attached to one of the parks near us in AB: > > > > > > > > > > > > > > > > > > > > daniel > -- > TRAFx Research > T: 403-678-1802 > F: 403-451-1561 > www.trafx.net > > New! TRAFx DataNet software. Take it for a test drive online at > www.trafx.net/datanet/demo > > > On Tue, Jun 16, 2009 at 12:16 AM, wrote: > >> *** >> * >> * >> * Please do not reply to this email. >> * >> *Use the OpenStreetMap web site to reply. >> * >> * >> * >> *** >> >> Hi Daniel Patterson, >> >> geobase:acrosscanadatrails has sent you a message through OpenStreetMap >> with the subject protected areas: >> >> == >> Hi there, >> I'm wondering what other tags you used for this import? >> I was hoping that more tags would be used, as the database shows more >> detail. >> >> Is this import listed in the bulk import chart? >> >> Please let me know you progress before federal parks start landing on my >> head :) >> >> Although i dont think it interfers with any of the CanVec data, for >> example. Pacific Rim National Park, the label already gets shown, but not >> the park boundaries. >> >> Unfortunatly, i don't get the talk-ca messages as they get sent, for some >> reason i only get the digest, so you might have already messaged the list >> about this. :) >> >> Thanks, >> Sam Vekemans >> Across Canada Trails >> == >> >> You can also read the message at >> http://www.openstreetmap.org/message/read/50676 >> and you can reply at http://www.openstreetmap.org/message/reply/50676 >> >> *** >> * >> * >> * Please do not reply to this email. >> * >> *Use the OpenStreetMap web site to reply. >> * >> * >> * >> *** >> > -- Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
On Wed, Jun 17, 2009 at 12:57 PM, "Marc Schütz" wrote: >> I think the definitions really don't belong in the the data -- perhaps >> if you want to see them, your browser should look them up in some >> table rather than load from the data. > > +1 > > It should be sufficient to keep the canvec:UUID, source and attribution tags, > and maybe a few of the other canvec:* (CMAS?). I don't see why we would need > most of the others. If someone is really interested in them, they can look > them up in Canvec using the UUID. > > created_by should be removed, too. This is better moved into the changeset. > One could even argue that "source" belongs there, too. I'll chip in here too - for those who aren't digging into the data, here's a typical church: * canvec:generic_code: 2010009 * canvec:value_definition: A building serving as a place of worship or residence for Christian or non-Christian religious order. Religious building includes: convent; church; non-Christian place of worship; monastery. * canvec:datasetName: 092C16 * created_by: canvec2osm * canvec:VALDATE: 1989 * canvec:CODE: 2010390 * amenity: place_of_worship * canvec:PROVIDER: Federal * canvec:entity: Building - ( Bâtiment ) * canvec:entity_definition: Permanent walled and roofed construction. * canvec:Theme: BS Buildings and structures * source: CanVec_Import_2009 * canvec:value: Religious building - ( Établissement religieux ) * attribution: Natural Resources Canada * canvec:UUID: 7bd7174ca8664fff8fe60c11853ceb73 * canvec:Planimetric Accuracy (CMAS): 30 * canvec:source: CanVec_Feature_Catalogue_Edition_1_0_2.pdf That's a ridiculous number of "uninteresting" tags. So, so much of this isn't useful for OpenStreetMap. Keep: amenity canvec:UUID Move onto changeset, since they are identical for everything in that changeset: created_by source attribution Remove: Everything else. Really, the point of OSM isn't to keep a copy of the Canvec data - it can all be referenced externally for the 0.0001% of OSM users who are interested. Otherwise our DB is being filled with data that isn't needed for our project. Cheers, Andy ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
Hi, 2009/6/17 Sam Vekemans : > http://www.openstreetmap.org/?lat=48.8221&lon=-124.053&zoom=12&layers=B000FTF This looks really nice and I'm happy to see the POIs converted too. > > You can see alot more detail on this area. The only feature that isnt loaded > is the big polygon of wooded area, (that'll take the bulkUpload.pl script > (that i still need to figure out) thats why im at beta 0.74 (im sure > it's not that hard to learn, i just havent got to it yet. I have at http://www.openstreetmap.pl/balrog/bulkupload/ a bunch of very simple upload scripts in python that I use for my bulk uploads. (I'm wondering if I should clean them up and ask someone to put in the svn along the perl and php versions because this version has some neat features like splitting and upload progress indication) > > So I look forward to all your nit pickings. I think the definitions really don't belong in the the data -- perhaps if you want to see them, your browser should look them up in some table rather than load from the data. Also I noticed the schools in Lake Cowichan are buildings according to the canvec data but don't have a building=* tag. Another nit pick is that the tertriary road with ref=18 is not connected with the other roads. There is probably no way to do this part automatically. I tend to do this manually always *before* uploading to OSM. Cheers ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
> I think the definitions really don't belong in the the data -- perhaps > if you want to see them, your browser should look them up in some > table rather than load from the data. +1 It should be sufficient to keep the canvec:UUID, source and attribution tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we would need most of the others. If someone is really interested in them, they can look them up in Canvec using the UUID. created_by should be removed, too. This is better moved into the changeset. One could even argue that "source" belongs there, too. Regards, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [nzopengis] LINZ -> OSM data import scripts, Garmin codes
2009/6/19 Sam Vekemans : > You all seem to be having the same (IDENTICAL) issues that im (talk-ca > list) are having with the CanVec data, &geobase please join in on the > talk-ca list as your ideas are valuable, and of mutual benifit :-) right, i'm sure we can learn off each other > the talk-ca list has less than 100 subscribers. > With only a few of us working on geobase, and even fewer working on CanVec. > > We too want to make the map Garmin happy, as well as conform to OSM > standards. > And ALSO want to make the best of the available data. > > Are there LINZ people who are also mappers? That helps. > > Is there the same issue about how the data is sometimes old? yes, but nzogps keep it up to date, and it's their data we're importing rather than the data direct from linz > Hopefully your following along with the RoadMatcher progress, as well > as the latest for Vancouver Island CanVec sample area. i wasn't no; is there a website we can look at, to see what's happening/a page on the osm wiki? we have the beginning of an osm wiki page, but not much too it. perhaps it needs populating more? http://wiki.openstreetmap.org/wiki/LINZ > So far, the only solution (for roads) is manual attaching to OSM > data.This will make it routable. The downside is that its anoying, and > takes almost as long to just trace it. in nz, we seem to have either areas with really good coverage that need very little work to finish (auckland city, chch, wgtn), or none at all. there aren't a huge number of places which are in between. so, i think it's not too bad a situation. good thing is this matching can be done via the web, without visiting the area, so many people can help out like with the recent tracing in hamilton - i would guess not many of the tracers were in that city ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec update and talk-ca subscribe
For some reason i havent been getting all the emails people send to talk-ca list. I changed the settings, hopefully it will work now. Anyway, for a useful message. Im on CanVec2osm v0.75 and it how can convert french accents where before it showed up as squares. Also, i have more of the 092c area loaded, and looks like its only dead-end_geobase, that i need to fine tune as well as dealing with the large polygons, then it'll be ready to launch. The Canada Day aim is an appropriate fit :) Once the script is released from BETA, that means that any more changes to the script will require that anyone who has uploaded data would need to re-upload the area. That's why it's important that the changesets are VERY clear on what is being imported. You can see the history of the area, as it shows eactly whats going on. http://www.openstreetmap.org/history?bbox=-124.3579%2C48.4153%2C-124.0469%2C48.5143 Any ideas are welcome :) Cheers, Sam vekemans Across Canada Trails Twitter: @Acrosscanada Facebook: http://www.facebook.com/sam.vekemans ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ontario 040P
Just a heads up that the next NRN release for Ontario, schedule for this summer (around August), will include street names and address ranges from closest to source NRN providers. Guy -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Adam Glauser Sent: 16 juin 2009 13:10 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Ontario 040P I've found (and since corrected) a couple more false-positive matches. Ways 35518380 was name="Old Oak Place", statscan:rbuid=3357619. These tags should actually have been applied to way 35521248. The correct tags for the first way are name="Aspenwood Place", statscan:rbuid=3357613. Way 35502496 was name="Willow Wood Drive",statscan:rbuid=3357623. Should be name="Woodrow Place",statscan:rbuid=3357623. This is tricky in part due to one Statscan feature corresponding to two different Geobase features (the entrance to the cul-de-sac and the circle-with-middle-barrier part). I'll continue to report these unless I hear otherwise - I'm still new here, if this is just noise please let me know. Also, thanks to Steve's pointers about OpenJUMP and the StatsCan road name data, I've given names to a bunch of ways that Roadmatcher couldn't resolve, along with their StatsCan RB_UIDs, using a combination of the .shp file from the StatsCan website and local knowledge of the layout of the roads. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [nzopengis] Re: DOC and LINZ Data under Creative Commons Licence
Hi Richard, Perhaps you will be able to be of assistance to our New Zealand friends? It looks like they have recently gained permission to use government data for OSM. Considering you were able to work with GeoBase directly to kick start the Canada import, and are the main contact as the OSM - Canada representative. (and will be speaking to the group at SOTM in Amsterdam. ) ... You mht be able to provide some assistance to the group. What we did (and are doing), is on all communications, we cc: talk-ca@openstreetmap.org message board. For each time people connect with the 'outside' world. Right now, for the GeoBase data, it's actively being imported at various spots across the country, and the CanVec data import hasn't officially started yet. I'm happy to be of assistance to those working on the LINZ & DOC data charts, Are you using shp2osm or shp-to-osm or another script for converting the data? Thanks, Sam Vekemans Across Canada Trails On 6/20/09, Andrew Simpson wrote: > > On Sat, 20 Jun 2009 17:41:33 +1200 > Robin Paulson wrote: > >> >> t2009/6/20 Andrew : >> > When I last looked there wasn't much activity in this group. I posted >> > a message about the LINZ and DOC data released under the CC Licence >> > (at Koordinates.com) on the OSM Legal list and got a lukewarm >> > response. >> > >> i think we need to be careful when talking to orgs like linz, doc, >> etc. this is something we discussed a year or so back - if lots of us >> make lots of requests to them (one person asking about cadastral, one >> about walking tracks, one about roads, etc, etc.), we were concerned >> they would get annoyed with multiple questions. personally i think we >> should leave it to one person, who contacts them about everything we >> want, in one shot, to disturb them as little as possible. remember, >> we're not paying them, and are expecting them to put in a fair amount >> of work, both legal and technical >> > > Rob - I'll reply to your email, but I try to tie together several > threads at once. > > Fully agree that we must not upset these organisations. I only > approached them after not raising any interest on the osm legal mailing > list (Actually they suggested that I contact LINZ!). > >> linz have already replied to simon that it's ok to use their d ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
