Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM
-Original Message- From: Stewart C. Russell [mailto:scr...@gmail.com] Sent: Monday, March 19, 2012 4:22 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Wind farm access roads that really shouldn't be in OSM I've notice a few ways in OSM like this one: http://www.openstreetmap.org/browse/way/39334713 that really shouldn't be in the database. They're GeoBase imports via the NRN. They're not tagged in any way that would allow removal. There is no public access on these roads. They're mostly gated closed. I don't know how they would have made it into the NRN. cheers, Stewart highway=unclassified seems to mean owned by someone other than a province or city to GeoBase, which is wrong. I'd just retag as highway=service, but it definitely belongs in the DB if there's a road or path there, just not tagged like it is. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM
-Original Message- From: Stewart C. Russell [mailto:scr...@gmail.com] Subject: Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM On 12-03-19 19:45 , Paul Norman wrote: I'd just retag as highway=service, but it definitely belongs in the DB if there's a road or path there, just not tagged like it is. But it's not a highway, which implies access. There is no access. The particular one I tagged, given the amount of illicit grow-ops in the area, would very likely get you escorted off by the OPP. If OSM has it shown, wouldn't it encourage attempted access? highway=service with access=no or access=private then. Many service roads aren't open to the public. If the road is there and is a service road, it's mappable. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Township of Langley roads background layer
I have finished my translation file for the Township of Langley roads data. The resulting output is available at http://maps.paulnorman.ca/langley/Roads-201204.zip Included are the shapefiles, ogr2osm translation file, and .osm output file. This file is not to be blindly imported, but used as another source when mapping or tracing roads. The spatial accuracy seems better than CanVec although CanVec also has lanes data. I intend to ask the TOL GIS department if they have lanes data. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] City boundaries on the Canada/US border
There are a significant number of cities in BC and Washington which have borders that in practice[1] coincide with the Canada/US border. Currently in OSM these are represented with many nearly-overlapping ways. The Canada/US border here consists of the BC-WA border, BC-ID border, BC-MT border, AB-MT border, SK-MT border, SK-ND border, etc. There are separate ways for the cities on the Canada side and cities on the US side. I am considering replacing these with one set of non-overlapping border ways. This would involve splitting the ways whenever a city ends or begins on either side of the border. The border would then consist of a BC-WA border in the water, a Surrey-Whatcom County border (in the water), a White Rock-Whatcom County border, a Surrey-Whatcom county border, Surrey-Blaine border, Langley-Blaine border, Langley-Whatcom County border, Abbotsford-Whatcom County border, Abbotsford-Sumas border, etc. This would reduce the number of ways present when you download a section of the border and have many advantages. The one big disadvantage is that it would boost the number of ways in the Canada and US relations. This increases the chance of conflicts and also increases the number of places it could be broken. Either way, the Canada/US border will remain very complex with so many different boundary relations ending there. If I do this, I will also align the borders to the IBC data (PD). I've investigated the accuracy of their data, and it agrees with the markers on the ground to within 10cm. I believe the most significant source of error in their data is the NAD83 to WGS84 conversion. [1]: The actual legal situation is much more complicated and serves as a good example of the problems that arise when you define what is supposed to be one line in multiple ways. The biggest oddity is that the Washington border extends out of the United States into Canada. All of the other oddities are just a few meters at most. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces
Since no one has objected (or commented) I'll go ahead with this if I can get it in before the rebuild starts. -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Saturday, March 17, 2012 12:04 AM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces Not listed in this message was the area this would be over. This would only be over the lower mainland unless requested for another area. -Original Message- From: Paul Norman [mailto:penor...@mac.com] Subject: [Talk-ca] Proposed mechanical edits: GeoBase/CanVec Service Surface and GeoBase/CanVec name spaces The GeoBase and CanVec imports in the lower mainland suffered from two tagging errors I propose fixing with two one-time mechanical edits. 1. surface=unpaved service ways GeoBase and CanVec highway=service ways are mis-tagged with surface=unpaved regardless of if they are paved or not. I propose removing this tag as it is misleading. To avoid removal of this tag where a mapper has reviewed it, I will only do the obvious cases automatically and review the others. The obvious case is ways where none of the tagging has changed since the import with the possible exception of geobase:uuid which may have been combined with the value from another way in a merge. These will be identified by the tags attribution=GeoBaseR geobase:acquisitionTechnique=Orthophoto geobase:datasetName=NRN:British Columbia geobase:uuid=* source=Geobase_Import_2009 surface=unpaved highway=service 2. Double-spaced names GeoBase and CanVec sometimes have names with two spaces in them. For example, West 70th Street. I propose fixing these. Unfortunately this is less automated and will require searching through the road network with JOSM for name: . The edit will be from my imports/mechanical edit account and appropriately documented. As these edits will require touching a large number of roads I also propose cleaning up unnecessary meta-information from the import that is duplicated by other tags. For example, geobase:datasetName=NRN:British Columbia can be inferred from source=Geobase_Import_2009, being located in BC, and matching highway=*. It is not worth creating a new version of objects solely to remove these tags, but since fixing the tagging requires creating a new object anyways it is worth doing it in this case. ___ 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 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] upcoming Canadian press coverage and your local group
From: Richard Weait [mailto:rich...@weait.com] Subject: [Talk-ca] upcoming Canadian press coverage and your local group Dear all, I expect that OSM will be getting some press coverage in the Canadian media in the near future. This is a wonderful opportunity to launch your long-anticipated local OSM group. I would love to see future awesome Canadian local OSM groups get launched TODAY. Pick a place convenient for you, and not-horrible for others. I use coffee shops and pubs, depending. Pick a time convenient for you and not-horrible for others. I use after work on a weekday. Announce it. Announce it here and in places where locals who aren't already OSMers might find out about it. I use meetup.com, you might use upcoming, or patch or anything else. There is a chance that the upcoming press will lead to new mappers who will be really grateful to have a local help them with their first edits. And you'll get to meet other local mappers who have been waiting for somebody else to start a local group. Be somebody else. :-) Please consider doing this. There is no good reason for Toronto to have all of the fun. :-) There are awesome OSM folks in Ottawa and Montréal, Québec and Sherbrooke and BC and Alberta and the far North. Come on. Meet and talk. Anyone else in the Vancouver area interested in this? I'm busy with exams until mid-next week but I'm free then. I live in New West and commute to UBC or Richmond. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] coastline or water polygon
From: Andrew Allison [mailto:andrew.alli...@teksavvy.com] Sent: Saturday, April 14, 2012 6:55 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] coastline or water polygon Hello: I'm removing red dots on the north coast of Nova Scotia at the moment with canvec data. The canvec data has a bunch of polygons for the coastline. Is there any strong arguments which is better either natural = coastline vs polygon of water? Coastline = updates slowly, but smaller ways water = updates faster but larger and less intuitive . Andrew The data in Nova Scotia in OSM is broken. Someone imported large natural=water polygons on the coast over existing data. I fixed about half of the imports and haven't had time to get back to the rest. The coastline should *not* be mapped with natural=water. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
From: Richard Weait [mailto:rich...@weait.com] Subject: [Talk-ca] Canadian imports: good or bad? Dear All, Let's talk about it again. How do we feel about the bulk copying of information from a permitted source into OpenStreetMap in Canada? To be clear, I'm not suggesting that we discuss whether external data sources are good or not. External data sources are good. I'm suggesting that we review how we best make use of those external sources. Although CanVec is unquestionably a useful data source for aiding with mapping, I question dumping in data that will never get looked at or improved by a mapper which is what is happening in widespread areas. This is not about using CanVec in conjunction with a survey to speed mapping, this is about using CanVec where you are unfamiliar with the area and no one will ever survey. While we're on the subject of CanVec, I think the documentation needs some work. People are importing CanVec without giving it a detailed look, trusting it's representation to be correct. It is not enough to just tie in the CanVec data with existing data. The CanVec data in some areas is wrong (e.g. coastlines in CanVec 8) and cannot be imported as is. Also you need to be aware of the age of some of the data sources. In parts of BC you should not import the streams from CanVec without verification with imagery. The names are generally alright, but many of the streams have dried up or been paved over in the last 30 years. Similarly, no one should be importing the buildings from CanVec in BC. They're wrong more far more often than they're right. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
From: Ian Bruseker [mailto:ian.bruse...@gmail.com] Sent: Sunday, April 15, 2012 9:31 PM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On 2012-04-15, at 6:37 PM, Steve Singer st...@ssinger.info wrote: I also feel that not of all data sources are equal. Even within Canvec some layers are excellent (ie roads and lakes in most of the country) while others are often so out of date it isn't worth the time to import (ie buildings in much of Southern Ontario) That's the third mention in a row of bad building data in Canvec. I'll chime in on that to say I found a hospital in St. Albert, Alberta that was marked as having come from an import. The hospital hasn't been there for 20 years. The new building is several kilometers away. Not just bad, full on dangerous if someone actually believed the data in OSM and tried to find help when they were hurt. :-( I thought it was just BC but it sounds like it's everywhere. Would I be correct in summarizing the opinions so far as 1. The buildings data from CanVec should not be imported unless it can be verified against imagery, in which case you might as well trace the buildings from imagery. 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM Publicly available WMS server?
Websites normally use TMS for backgrounds, not WMS. WMS is generally a lot slower than TMS. http://wiki.openstreetmap.org/wiki/WMS might help with finding a WMS server for OSM data. To make your own WMS server you could either use a program that turns tiles to WMS or renders directly to WMS. There's a few listed on that wiki page. There are plugins for QGIS that allow you to use a TMS background. There's an OpenLayers one that comes with a preset for osm.org mapnik. I use it and it works. You could also point QGIS at an osm2pgsql database although I don't suggest this if you are looking at a large area or import the entire planet into the database. From: Firmin,Mark [Ontario] [mailto:mark.fir...@ec.gc.ca] Sent: Friday, April 20, 2012 10:53 AM To: talk-ca@openstreetmap.org Subject: [Talk-ca] OSM Publicly available WMS server? Hello All, I may have asked this question a while back, but does anyone know of a publicly available open street map web mapping service that I can connect a wms client to? I have seen some really interesting websites that have a OSM underlay and I am assuming this is done using WMS. In the most recent Kubuntu OS, I've seen OSM used as a desktop background that you can interact with (zoom/pan). Amazing. I am using QGIS to verify some data and I would like to us OSM as an underlay. Thanks, Mark Firmin ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. If no one disagrees with the fact there is not a consensus that importing CanVec without minimal verification is acceptable I'll go ahead and document on the Wiki, using Andrew Allison's examples. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Subject: RE: [Talk-ca] Canadian imports: good or bad? Steve, Paul, I was on the impression that the consensus was more about using Canvec where it is the best available source and, when it is not, the data could be imported, but only after an exhaustive verification using available data/imagery. Whatever is the consensus, it should be documented in the wiki. Furthermore, I think that internal consistency/accuracy/existence should be defined... consistency: ? CanVec sometimes contradicts itself, for example it has trees in the water frequently. The coastline example I sent to you earlier would also be another example of where the data doesn't make sense. There are a few others that I've encountered. Typically what happens is one data source is significantly older than the other so CanVec says the land is being used for two contradictory uses at the same time. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] FW: [Talk-us] City boundaries on the Canada/US border
Whoops - forgot to include talk-ca@ in this -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Wednesday, April 25, 2012 1:50 PM To: 'Toby Murray'; talk...@openstreetmap.org Subject: Re: [Talk-us] City boundaries on the Canada/US border I started working my way across and the cleanup is progressing. I'm up to monument 31 so far. Once I get out of populated areas it should go quicker. The monuments are physically present on the ground, so their location could be improved by more accurate surveys. However, I doubt if any consumer GPS would be more accurate. The points agree with multiple sources of accurate imagery within the resolution of the imagery. I settled on ibc:ref for the turning points which don't have a survey_point on the ground. Those refs help me keep track of where I am. Starting in the water and going east, the border is now Delta-Whatcom County Surrey-Whatcom County White Rock-Whatcom County Surrey-Whatcom County Surrey-Blaine Langley-Blaine Langley-Whatcom County Abbotsford-Whatcom County Abbotsford-Sumas -Original Message- From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Friday, March 30, 2012 7:51 AM To: talk...@openstreetmap.org Subject: Re: [Talk-us] City boundaries on the Canada/US border On Fri, Mar 30, 2012 at 7:18 AM, Alexander Roalter alexan...@roalter.it wrote: Am 30.03.2012 11:17, schrieb Paul Norman: There are a significant number of cities in BC and Washington which have borders that in practice[1] coincide with the Canada/US border. Currently in OSM these are represented with many nearly-overlapping ways. The Canada/US border here consists of the BC-WA border, BC-ID border, BC-MT border, AB-MT border, SK-MT border, SK-ND border, etc. There are separate ways for the cities on the Canada side and cities on the US side. ... This would reduce the number of ways present when you download a section of the border and have many advantages. The one big disadvantage is that it would boost the number of ways in the Canada and US relations. This increases the chance of conflicts and also increases the number of places it could be broken. I merged the us/canadian border with the north dakota, minnesota and montana state borders and also county borders a while ago, and I agree that there should only be one way for one part of the border, this line being shared in all affected boundary relations. I don't really think this will increase conflicts, as if you delete one way of a border, all affected relations will be notified (at least in JOSM it's impossible to download a way without downloading all relations this way is connected. I did include city boundaries where available, but this was the case only on one city (Emerson, MB). In Europe, nearly all borders are made up of individual municipality border stretches (I once loaded italy's circumference, made up of 2500 ways). The problem with conflicts is if someone is splitting ways that are members of the US border relation down in Arizona while you are doing the same up in Washington. But in general I don't think this will be a huge problem. Much of the US border is either in water or sparsely populated areas where frequent edits are unlikely. I've done some splitting of ways for counties along both the north and south border so I think this would be fine too. Overlapping ways are a pain to deal with. Then again relations can be a pain too :) But at least they are cleaner. Toby ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Proposed import: Service New Brunswick address data
-Original Message- From: webmas...@the506.com [mailto:webmas...@the506.com] Sent: Thursday, June 21, 2012 10:51 AM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Proposed import: Service New Brunswick address data Hello...long time reader, first time poster. You may know me as the one who did (sometimes botched) the bulk of Canvec imports in New Brunswick. That job was completed last week. As you may be aware, Canvec does not include road name or addressing data in New Brunswick. I have generally been using a combination of the StatsCan and Service New Brunswick databases to add road names by hand. It was a long and arduous process that took over a year, but it's finished. Service New Brunswick maintains a publicly-available geocoded database of civic address points in the province (http://www.snb.ca/gdam- igec/e/2900e_1f_i.asp), and their license (http://www.snb.ca/gdam-igec/e/2900e_1e_v.asp) is compatible with OSM. My experience is that the database is very accurate in urban areas, but there are still a lot of gaps in rural areas. Any records that do not currently have a civic number attached will not be imported, and duplicate addresses will be ignored. There are currently very few addresses in NB in the OSM database. They are mostly in downtown Fredericton and uptown Saint John, and those areas will be checked by hand to avoid duplicates. In the rest of the province, an attempt will be made to merge the data with existing ways whenever possible. Each point would have the following tags: addr:housenumber= addr:street= addr:city= addr:province=NB addr:country=CA addr:source=SNB addr:SNBid=unique ID from the SNB database I haven't looked at the data yet, but I would suggest omitting addr:province and addr:country from an import. That was the conclusion of the Surrey addresses. As these addresses are in a fairly unusual format, could you post a sample of a rural area and an urban area in .osm or as a shapefile? Also remember to consult with imports@ when you're working through the import process. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec...
-Original Message- From: Fabian Rodriguez [mailto:magic...@member.fsf.org] Sent: Saturday, June 30, 2012 4:16 AM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec... On 06/30/2012 03:51 AM, Frank Steggink wrote: Nicolas, thanks a lot for the data and the information! Of course the first page I went to was the License page: [1] Unfortunately this license doesn't seem to be compatible with any of the current OSM licenses (neither CC-BY-SA nor ODbL). [...] Speaking not only for this project but for others too, what license is best to be used when collection data, and making sure such data can be used in OSM without problems? PDDL (http://opendatacommons.org/licenses/pddl/) leads to the easiest reuse by different projects. It is used by Surrey, Langley and Winnipeg Transit. It is unquestionably compatible with the license used by every project I am aware of. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] redaction bot coming soon!
From: Richard Weait [mailto:rich...@weait.com] Subject: [Talk-ca] redaction bot cbbboming soon! Dear All, The redaction bot is now in North America. You can watch the progress here: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Each area starts from the southern end, so it may take a little time to reach the Niagara peninsula. :-) The bot has completed most of the south of Canada. Victoria, Edmonton and parts of Winnipeg seem to be the only big cities left. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] redaction bot coming soon!
The logs (linked from that square) say which way it was. It looks like the maritime boundary was large enough that two instances of the bot tried to delete it at the same time From: Bruno Remy [mailto:bremy.qc...@gmail.com] Sent: Wednesday, July 18, 2012 7:43 PM To: Paul Norman Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] redaction bot coming soon! oops. some errors in Port Simpson area (BC) http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=10 http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=10lat=54.58503lon=-130.28543layers=B00FTTFF lat=54.58503lon=-130.28543layers=B00FTTFF is there a way to check some logs to see whats wrong and were? 2012/7/18 Paul Norman penor...@mac.com From: Richard Weait [mailto:rich...@weait.com] Subject: [Talk-ca] redaction bot cbbboming soon! Dear All, The redaction bot is now in North America. You can watch the progress here: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Each area starts from the southern end, so it may take a little time to reach the Niagara peninsula. :-) The bot has completed most of the south of Canada. Victoria, Edmonton and parts of Winnipeg seem to be the only big cities left. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Bruno Remy ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec imports allowed again?
From: David E. Nelson [mailto:denelso...@yahoo.ca] Subject: [Talk-ca] CanVec imports allowed again? Now that the redaction bot has apparently finished its sweep of Canada, is it safe for CanVec imports to be resumed? I want to try my hand at importing a few tiles around where I live. The bot is still running. It shouldn't impact mapping although uploading frequently is always a good idea. Imports are still not to be done. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Disgardable NHN and NRN tags
This is based on http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008830.html, a recent talk-us@ discussion about TIGER tags. Parts of this message are a copy/paste from there. Some people may not even be aware of this but JOSM silently discards the created_by tag if it exists on any object you change and upload to the API. This tag was deemed unnecessary and counterproductive a long time ago and this is just a way of cleaning it out of the database as people edit. Not sure if Potlatch does anything like this. I think some of the tags from the GeoBase NHN and NRN imports can be silently dropped too. I think the following can be safely dropped: geobase:datasetName geobase:uuid accuracy:meters waterway:type sub_sea:type Any thoughts? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Disgardable NHN and NRN tags
From: Adam Dunn [mailto:dunna...@gmail.com] Sent: Sunday, July 29, 2012 5:57 PM To: Steve Singer Cc: Paul Norman; Toby Murray; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Disgardable NHN and NRN tags I'd keep the accuracy:meters around. I've used that for other things (mainly denoting how accurate my gps is in obtaining geodetic survey markers, or what the accuracy is based on number of sample points being averaged). Wouldn't want JOSM to be wiping those out. Why not accuracy instead? But ya, if you're using it then it'll need to be kept. I think the ways tagged with sub_sea would need to be deleted, not just the tag itself. These tend to be hydrological topology connectors under lakes that show how rivers are connected. The entire way should be deleted to bring it in line with the rest of OSM. Most of them need converting to waterway=stream (or other tags as appropriate) and sub_sea deleting. A lot of them are small ponds or streams where there would normally be a way. Not too sure about the waterway:type tag. Might be used in other places for other things? Taginfo shows only the imported values - I doubt anyone is using this. Can't think of anything stopping us from getting rid of geobase:* tags. Canvec imports don't have this, so it's inconsistent across the country, and it's probably not used anywhere else. The ones I listed were from BC - are there others elsewhere that also need removing? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Talk-us] Discardable TIGER tags
From: Toby Murray [mailto:toby.mur...@gmail.com] Sent: Tuesday, July 31, 2012 6:40 PM To: talk-us Subject: Re: [Talk-us] Discardable TIGER tags I was unaware of the TLID bug and the fact that TIGER has changed their data model although I kind of wondered about this because I didn't see a TLID attribute in the new TIGER shapefiles. I guess the new field is LINEARID? So yeah, that makes the tlid tag completely useless then. So, I think I'm going to submit a patch with the following tags: tiger:upload_uuid tiger:tlid tiger:source tiger:separated Based on http://lists.openstreetmap.org/pipermail/talk-ca/2012-July/004948.html please also add geobase:datasetName geobase:uuid There's still talk about some other values that might need adding to the list from some Canadian imports, but there's no disagreement about those two. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Disgardable NHN and NRN tags
From: Paul Norman [mailto:penor...@mac.com] Sent: Sunday, July 29, 2012 8:14 PM Subject: Re: [Talk-ca] Disgardable NHN and NRN tags I think the ways tagged with sub_sea would need to be deleted, not just the tag itself. These tend to be hydrological topology connectors under lakes that show how rivers are connected. The entire way should be deleted to bring it in line with the rest of OSM. Most of them need converting to waterway=stream (or other tags as appropriate) and sub_sea deleting. A lot of them are small ponds or streams where there would normally be a way. Not too sure about the waterway:type tag. Might be used in other places for other things? Taginfo shows only the imported values - I doubt anyone is using this. Can't think of anything stopping us from getting rid of geobase:* tags. Canvec imports don't have this, so it's inconsistent across the country, and it's probably not used anywhere else. The ones I listed were from BC - are there others elsewhere that also need removing? sub_sea:type is okay to be removed - the only value in the database is inferred, it's only from the import waterway:type will be okay to remove once I deal with the 250 or so exceptional cases manually. As an aside, completing the rest of the NHN cleanup mechanical edit discussed and consulted on in 2011 (http://wiki.openstreetmap.org/wiki/Mechanical_Edits/pnorman_imports#NHN_Tag _cleanup) should deal with a lot of the objects. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] New Lower Mainland Imagery sources
After some technical and legal work, I now have a number of imagery layers hosted on a rented server. These layers cover from Vancouver to Hope in 20cm or better and Lions Bay to Pemberton as 40cm or better. 10cm imagery is available for Vancouver, Richmond, Ladner, West Delta, the North Shore, Whistler and Surrey. Most of the imagery was taken in 2009, but Surrey is from 2011. I've prepared a page with links to the imagery and Potlatc2 and JOSM URLs at http://imagery.paulnorman.ca/tiles/about.html Some layers may be slow initially loading at high zooms as they may need to fetch from a remote server. An example of two layers from there and Bing is http://imagery.paulnorman.ca/tiles/surreyexample.png. Starting in the top left going clockwise the layers are Surrey2011, DataBC bc_gvrd_east_2009 and Bing. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Lower Mainland Imagery sources
You're supposed to copy and paste the URL from the table or click on the
link, not copy the link. I'll see if I can clarify that in the
documentation.
From: Matthew Buchanan [mailto:matthew.ian.bucha...@gmail.com]
Sent: Tuesday, August 21, 2012 8:01 PM
To: Paul Norman
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] New Lower Mainland Imagery sources
I am adding it using the Add Imagery URL. (the + sign) then under TMS URL I
put in:
http://127.0.0.1:8111/imagery?title=DataBC%20bc_gvrd_west_2009
http://127.0.0.1:8111/imagery?title=DataBC%20bc_gvrd_west_2009type=tmsurl
=http://%7bswitch:a,b,c,d%7d.imagery.paulnorman.ca/tiles/bc_gvrd_west_2009/%
7bzoom%7d/%7bx%7d/%7by%7d.png
type=tmsurl=http://{switch:a,b,c,d}.imagery.paulnorman.ca/tiles/bc_gvrd_we
st_2009/{zoom}/{x}/{y}.png
I leave Zoom empty, then hit ok.
-- Matthew Buchanan
-- Kamloops, BC
On 20 August 2012 18:26, Paul Norman penor...@mac.com wrote:
What string are you adding to the imagery list? Are you adding it in the
preferences window itself or opening the Add Imagery URL dialog?
Tagging presets are under the third tab down in preferences.
From: Matthew Buchanan [mailto:matthew.ian.bucha...@gmail.com]
Sent: Monday, August 20, 2012 1:46 PM
To: Paul Norman
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] New Lower Mainland Imagery sources
Paul
I haven't been able to get this to work. I add it to my list of layers in
Preferences, Imagery Preferences. It shows up in the Imagery menu, but then
I get multiple layers showing up in the layer list and they keep duplicating
themselves until JOSM runs out of memory.
Also, I'm don't know how to add the preset zip file into JOSM.
-- Matthew Buchanan
-- Kamloops, BC
On 18 August 2012 12:15, Paul Norman penor...@mac.com wrote:
After some technical and legal work, I now have a number of imagery layers
hosted on a rented server.
These layers cover from Vancouver to Hope in 20cm or better and Lions Bay to
Pemberton as 40cm or better. 10cm imagery is available for Vancouver,
Richmond, Ladner, West Delta, the North Shore, Whistler and Surrey.
Most of the imagery was taken in 2009, but Surrey is from 2011.
I've prepared a page with links to the imagery and Potlatc2 and JOSM URLs at
http://imagery.paulnorman.ca/tiles/about.html
Some layers may be slow initially loading at high zooms as they may need to
fetch from a remote server.
An example of two layers from there and Bing is
http://imagery.paulnorman.ca/tiles/surreyexample.png. Starting in the top
left going clockwise the layers are Surrey2011, DataBC bc_gvrd_east_2009 and
Bing.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
WebRep
chrome://wrc/skin/png/line-dark-horizontal.png
Overall rating
chrome://wrc/skin/png/line-dark-horizontal.png
chrome://wrc/skin/png/line-dark-horizontal.png
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec import issues
I see the problem as being the importing of everything as being the problem, not the geometric model :) From: Daniel Begin [mailto:jfd...@hotmail.com] Sent: Tuesday, August 21, 2012 1:49 PM To: 'Pierre Béland'; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec import issues Bonjour Pierre, The Canvec Geometric Model is explained in the following OSM wiki page ... http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model The model was adopted after discussions with the community. The model was designed to simplify the import of a selection of features by the contributors, instead of imposing import the entire contents by them. However, history now shows that the community usually imports the entire content. Compromises always bring pros and cons.!-) Best regards, Daniel _ From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: August-21-12 16:04 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec import issues I didn't do Canvec imports too much. Looking at various lakes in wooded areas, I now realize that Canvec imports are often (always?) duplicating lakes. I do'nt know what was the reason to create these duplicate ways in the Canvec import file. Should we duplicate the lakes to apply a inner role in the relation? Is this a reason for that? Or could we instead simply use the existing lake with a inner role in the wooded area polygon relation? Pierre _ De : Frank Steggink stegg...@steggink.org À : talk-ca@openstreetmap.org Envoyé le : Mardi 21 août 2012 13h32 Objet : [Talk-ca] Canvec import issues Hi, Today I was contacted by someone inquiring (with a somewhat hostile tone) after the Canvec import I've done over the weekend northwest of Montréal. He was not really happy with the way how the import has handled. The way the Canvec data is currently provided, leaves some room for improvement. I'm not sure if all his issues have been discussed in the past (since I haven't followed all Canvec discussions, especially in the beginning), but I could see some merit in some of the point. Some examples he provided come from the Mt. Tremblant area [1]. Note that the lakes (and most of the streams) were imported previously by someone else, based on NHN data, but the same issue plays with the Canvec data itself. (This left me to the task to leave the Canvec lakes out of the upload, as well as most streams.) On the left you see Lac Ouimet. He mentioned that a large part of the ways are duplicated. The outer boundary of the wooded area is a separate polygon from the lake itself. However, Lac Gauthier on the right is a different case. This lake has been cut out from the woods, and I left the inner boundary intact. JOSM is not complaining about this. Since dealing with multipolygons remains a sticky issue, I have not done that. I think it would be better to take care of these issues with some tool. Although using a tool is considered dangerously (and rightfully so!), dealing with multipolygons is prone to errors as well. Another issue is that some lakes do not have names, but contain a separate node (not part of any of the ways) with natural=water and name=* tags. I can only assume that this comes from the source data. In many cases it is hard to determine the extent of the lake, since it can gradually taper into a river. This was not mentioned directly by the user, but I thought he was referring to this. His issue turned out to be somewhat different. There is a place node near Lac Gauthier, with the same name. I explained to this that this must be the name of a hamlet. The non-official tag place=locality is probably due to this confusion. This name is also visible on the original topo map [2]. Furthermore he noticed that I have duplicated his address nodes and ways. This was an omission, so I have corrected this. I scan the existing data in order not to duplicate existing features. Of course this is prone to errors as well, especially in a large area which is void of address nodes and ways, except for two ways around a lake... I'm not asking anyone for solutions. I can easily think about them as well, but that doesn't make the problem go away. Thinking about the solution is the easiest part, but working it out and implementing it is much more difficult. It is more than simply typing in some code and then run it over the data. Instead of doing that, I have tried to explain him something about the hybrid data model OSM is using (not purely geographical, but also not purely topological). And of course there is also the gap between idealists and realists. I see the current state of OSM as the status quo, so I take it for granted. I think that Canvec falls within that status quo situation as well, otherwise the OSM data offered by NRCan would have looked differently, after all those years of discussions and reviews. I have invited this user to discuss the issues he found on talk-ca. I think that would be much more constructive than
[Talk-ca] Canada and US Imagery bounds
I've gone and updated the imagery bounds and bboxes for both Potlatch 2 and JOSM for the North American imagery sources. JOSM should now only suggest a source if it actually covers the area. Potlatch 2 will still suggest sources even if they don't cover the area because potlatch 2 only supports bboxes, not polygons and the bbox for most of the US sources looks like http://www.openstreetmap.org/?box=yesbbox=-124.819%2C24.496%2C-66.930%2C49. 443 I have also set up bc_mosaic, a source covering Greater Vancouver, Fraser Valley, and the Sea 2 Sky corrider up to Pemberton. Both JOSM and PL2 should suggest it. The source is the various sources listed on http://imagery.paulnorman.ca/tiles/about.html combined into one layer. The individual layers will be faster but not as convenient. To update the layer information in JOSM use the reload button to the right of the map on the Imagery Preferences tab of Preferences. You may of course find that if you live right on the border that some suggestions are not ideal but the error is now measured in hundreds of meters, not hundreds of kilometers. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] BC: New Port Mann bridge partly open
The surrey2012 should have some more from the south side. I'm thinking about going and driving back and forth a few times with my GPS and my camera set to auto so that I can get all of the exits. Anyone interested in a driving mapping party? Of course I'd get to redo it all in a couple weeks when they start the cape horn overpass work. From: Matthew Buchanan [mailto:matthew.ian.bucha...@gmail.com] Sent: Wednesday, September 19, 2012 5:48 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] BC: New Port Mann bridge partly open I updated the map to reflect the fact that the eastbound lanes of Highway 1 are now going over the new bridge. There are also some new ramps recently opened on the Coquitlam side. If someone can take a look to see that I haven't messed up the Hwy 1 relation. Still needs some work to clean up what's going on there. Some of the new structures are visible on the bc_mosaic layer, but we need some GPS tracks of them too. -- Matthew Buchanan -- Kamloops, BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Surrey 2012 imagery
I'm getting it from the City of Surrey.
If you get imagery under a compatible license I could look at hosting it.
City GIS departments generally have imagery but they may be reluctant or
unable to release it. Surrey releases their data and imagery under the PDDL
http://opendatacommons.org/licenses/pddl/summary/ .
One potential source is Orbview-3.
http://wiki.openstreetmap.org/wiki/Orbview-3 has some information. I had a
quick look but all I could find was a bit of imagery south of Sudbury from
June 2006 with 40% cloud cover.
From: James Mast [mailto:rickmastfa...@hotmail.com]
Sent: Tuesday, September 18, 2012 8:45 PM
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Surrey 2012 imagery
Paul, I'm just curious, but how are you getting this new imagery? Is there
a place where new Ontario imagery can be found? Only reason I'm asking is
because of 4 expressway projects that the info is needed for in Ontario (QEW
rebuild in St. Catharines where all the exits got changed; ON-400 extension
around Parry Sound; ON-69 South of Sudbury; and ON-11 between Emsdale and
South River). Bing for those areas is either out-of-date, or there is no
good imagery at all to use.
--James
From: penor...@mac.com
To: talk-ca@openstreetmap.org
Date: Tue, 18 Sep 2012 16:47:45 -0700
Subject: [Talk-ca] Surrey 2012 imagery
I added the new Surrey 2012 imagery to my TMS server. This imagery was
flown
around April 2012 and has a spatial accuracy of 10cm.
Unfortunately I've only got the 40cm resolution version right now, but
this
is still the most recent imagery available for the area. When your imagery
is more recent than the OSM data you don't have to worry about if the
feature you don't see in the imagery is still there.
Details (including the coverage) can be found at
http://imagery.paulnorman.ca/tiles/about.html
The URL for Potlatch2 is
http://${a|b|c|d}.imagery.paulnorman.ca/tiles/Surrey2012/$z/$x/$y.png
http://$%7ba|b|c|d%7d.imagery.paulnorman.ca/tiles/Surrey2012/$z/$x/$y.png
and
the Imagery URL for JOSM is
tms[10,18]:http://{switch:a,b,c,d}.imagery.paulnorman.ca/tiles/surrey2012/{z
oom}/{x}/{y}.png
Note that when I get the 10cm imagery the JOSM Imagery URL will change to
tms[10,20]:http://{switch:a,b,c,d}.imagery.paulnorman.ca/tiles/surrey2012/{z
oom}/{x}/{y}.png
___
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] [Imports] Importing CanVec better?
From: Maury Markowitz [mailto:maury.markow...@gmail.com] Sent: Monday, October 15, 2012 1:28 PM To: impo...@openstreetmap.org Subject: [Imports] Importing CanVec better? Newb here, so I hope this is the right place to ask. I also posted on one of the wiki talk pages, but I didn't know if anyone goes there. I have noticed that vectors imported from the CanVec database are split at grid boundaries. This means that large objects like roads or lakes are split into multiple parts in OSM. I strongly suspect that there is a way to re-integrate these into single objects, which would greatly improve things (case in point, the cottage would no longer be on a three-part lake :-) There are five different types of ways that can be split a tile boundaries. 1. Unclosed ways, like roads. It doesn't matter if these are split, but the ends need to share nodes so that they're connected. Splitting a road doesn't change the meaning. 2. Small closed ways, like buildings. These need to be joined into one closed way. 3. Lakes. These should be joined together, either as a closed way or as a multipolygon. 4. Large forests. These do not need to be joined. In fact, they need to be split at some point to avoid having a multipolygon the size of BC. 5. Coastlines (and the coast of lakes like the great lakes). In principle these are the same as other unclosed ways, but these should only be imported with those very familiar with both the CanVec water model and OSM coastlines. As this data is automatically imported, is this the right place to discuss this? CanVec isn't automatically imported. If people aren't performing the basic checks at edges you can send them a note or ask someone else to. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec 10 and landcover issues
From: Harald Kliems [mailto:kli...@gmail.com] Sent: Friday, October 19, 2012 11:04 AM To: Talk-CA OpenStreetMap Subject: [Talk-ca] Canvec 10 and landcover issues Hi everyone, I've done some OSMInspector debugging of areas around Montreal and I've come across a number of newly imported natural=wetland areas, sourced from Canvec 10. that are clearly wrong. This, for example, http://www.openstreetmap.org/?lat=45.69514lon=- 73.90455zoom=17layers=M is a subdivision, not wetland or wood. If you're importing Canvec data could you please make sure to do some plausibility checks, based on aerial imagery or road layout, especially in populated areas? I'm not sure how old the imported data is, but some areas supposedly covered by woods or wetlands look like they've been developed for quite some time. Yes - one of the frequent issues is that the different thematic layers (e.g. landcovers, addresses, roads, buildings, etc) are different ages and some are very old. In BC the buildings information is horrendously old while frequently the water and forest information doesn't agree - leading to CanVec saying there are trees in the ocean. The recent releases are better in this regards and I believe some zipfiles include information on the age of the different feature data included, but the problem of areas being described both as built up by the roads data and as forest by the other data is still frequently an issue. It's like your mixing pictures of what the area was like at different times, so you get confusing results. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec
Just a reminder, if youre proposing to import the admin boundaries, you need to follow the steps in http://wiki.openstreetmap.org/wiki/Import/Guidelines, which includes not just talk-ca@ but the imports@ mailing list. My recollection is that boundaries for statscan purposes sometimes differ from the true boundaries in subtle ways. Could you post a .osm of what you propose importing? From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: Saturday, October 27, 2012 4:04 PM To: talk-ca Subject: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec Au cours des dernières semaines, j'ai examiné les données pouvant être importées pour définir les limites administratives des municipalités, MRC et régions administratives du Québec. J'ai déja indiqué dans un courriel précédent, les données importées par des contributeurs à Saint-Jean-sur-Richelieu, Montréal, Labelle et Québec. De plus, des données importées pour Brossard et Laprairie sont mal définies et devront être corrigées. À mon avis, il faut éviter d'importer à la pièce les limites des villes, sinon le travail de vérification / correction sera immense. Pour deux municipalités ayant une frontière commune, si les limites sont différentes, il y aura beaucoup de travail de réconciliation. Sur le site des données ouvertes du gouvernement du Québec, j'ai fait une demande pour obtenir les limites administratives du Québec avec licence ODbl. Aucune nouvelle depuis quelques mois. J'ai examiné les données de Geobase ajoutées récemment pour le Québec. Suite à l'examen de cess données, je constate qu'il faut utiliser deux fichiers différents : 1. limites de municipalités (source initiale, gouvernement du Québec). 2. limites des territoires autochtones. J'ai constaté que certains territoires innus et tous les territoires inniuits sont absents. Les territoires non organisés, les MRC et les régions ne sont pas décrits. Comparativement, le fichier des limites de recensement de Statistique Canada est complèt. Une subdivision de recensement est une municipalité ou un territoire considéré comme étant équivalent à des fins statistiques (par exemple une réserve indienne ou un territoire non organisé). voir http://www5.statcan.gc.ca/bsolc/olc-cel/olc-cel?lang=fra http://www5.statcan.gc.ca/bsolc/olc-cel/olc-cel?lang=fracatno=92-162-XWF catno=92-162-XWF Les limites sont assez prêts de celles de Geobase. municipalités, territoires non organisés, territoires autochtones incluant innus et innuits, MRC et régions administratives. Je suggère donc que nous examinions la possibilité d'importer les données de Statistique Canada pour définir les limites administratives des municipalités, MRC et régions administratives. Je crois que le fichier le plus récent est à l'adresse suivante : http://www.statcan.gc.ca/pub/92-196-x/2011001/spa-fra.htm À mon avis, il vaudra mieux remplacer les limites déja saisies pour faciliter le travail et assurer une cohérence de l'ensemble de données. Est-ce que d'autres personnes veulent examiner ces données? Sinon, acceptez-vous que je procède à l'import de ces donneés pour le Québec? Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Suivi OSM / OSM Monitoring
From: James Ewen [mailto:ve6...@gmail.com] Sent: Monday, October 29, 2012 5:22 PM To: talk-ca Subject: Re: [Talk-ca] Suivi OSM / OSM Monitoring I see that Canada is pretty good at the admin2 (Country) level, and the admin4 level (Regions) except for a few islands in the Hudson and James Bay areas. It looks like BC has had the admin6 (Departments) level imported Yes - although they're honestly not particularly valuable data. The admin_level=6 entities are of much less practical importance than the admin_level=8 cities. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Suivi OSM / OSM Monitoring
From: James Ewen [mailto:ve6...@gmail.com] Sent: Monday, October 29, 2012 9:22 PM To: talk-ca Subject: Re: [Talk-ca] Suivi OSM / OSM Monitoring On Mon, Oct 29, 2012 at 9:14 PM, Paul Norman penor...@mac.com wrote: I don't know how it works in the rest of the country, but in Alberta, once an area declares itself a City, it gets separated from the county it may have been a part of as far as taxes and other funding are concerned. The urban node of Sherwood Park was for the longest time the world's largest hamlet. With a population of 65,000 it could easily become Alberta's seventh largest city, but to declare itself a city, it would need to draw an administrative boundary. If that boundary included the refineries east of Edmonton, then the rest of Strathcona County would lose a huge tax base, and be left with less money for administration. If the administrative boundary were drawn to just include the urban area, then Sherwood Park would be left with a large residential population used to the service levels available with a much smaller tax base to support them. Therefore the solution is to create the Specialized Municipality of Strathcona County that includes nine hamlets. So, while admin level=6 may be of little importance to you, there are a bunch of politicians, and other municipal government administrators that would argue otherwise. But your example doesn't involve any of the BC admin_level=6 boundaries I was talking about. Politically, culturally and economically they're viewed as less important than cities here. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] BC Resource Roads
I was importing some CanVec in northern BC and came across a resource road on bing, which I also added, but I realized I wasn't positive on the best tagging. A typical example is http://www.openstreetmap.org/?lat=59.395lon=-122.074zoom=16 These roads exist for forestry and oil and gas use. In this particular region they're primarily built for accessing oil and gas leases and have trucks running to/from the wells. They aren't generally used for through traffic. They are almost always unpaved but maintained to some minimum standard. There seem to be to be three obvious tagging choices (aside from highway=road which is never wrong) highway=track tracktype=grade1 highway=service surface=unpaved highway=unclassified surface=unpaved I am in favour of the first (track with tracktype) but would like to get some thoughts from others. As an aside, these roads are not in Google, CanVec or any other sources I quickly checked. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Subdivisions
From: Steve Roy [mailto:st...@ssni.ca] Sent: Monday, November 12, 2012 2:58 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] New Subdivisions What is the best was of adding a new subdivision like this one east of Kelowna? I've only used Potlatch. http://www.openstreetmap.org/?lat=49.873809814453125lon=- 119.35237884521484zoom=15 There's a few ways of going about doing this. Because you have aerial imagery (2011 provincial imagery) for the area it makes it easier. Generally the first step is to get the roads in. You could trace them from the imagery or in this case they are also in CanVec. If it was a really new subdivision you'd have to use a GPS. It looks like there might be some even newer construction not in CanVec or the imagery. Just for reference, the CanVec data is 082E14.0.2. The Wiki has more docs on CanVec, but basically in this case you'd only want to bring through the road data. The other data is rather useless. You can do this with JOSM or P2. Once the roads are in I'd suggest going to the subdivision and walking the roads, checking names and noting POIs. Getting the location of any retail locations is also useful. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec bug - splitting of long riverbank ways?
I appear to of found a CanVec 10 bug in 094P13.0.osm There is a waterway=riverbank way (Dilly Creek) that is split in two at 59.7728641, -121.9806992. One way is 2k nodes, the other is 457 nodes. Ideally this would be split in two to form two separate areas. An alternate solution would be to not split them and have one way over 2k nodes. This will force the importer to fix it before uploading as opposed to right now where if someone doesn't notice they will upload broken data. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Import Canvec : micro-tâches / Canvec imports micro-tasking
I have wondered about setting up a snapshot-server and loading CanVec on it then setting up a P2 deployment pointing at it. The problem with splitting by layers is that OSM data is not divided by layers (including planet files). In general if you have interdependent layers and you want to use them with OSM the first step is to merge the layers into one. Now although CanVec appears as multiple independent layers (one .osm file) the underlying data comes from multiple sources (NRN, NHN, etc) so some layer splitting would be possible. If I get time Ill merge together some subtiles to a NTS tile and throw them on my hetzner server. Its not ideal since its in Europe and doesnt have the disks Id want, but its good enough to serve as a proof of concept. From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: Tuesday, November 13, 2012 12:02 PM To: talk-ca@openstreetmap.org Cc: Paul Norman; Nicolas Gariépy Subject: Import Canvec : micro-tâches / Canvec imports micro-tasking Data import is essential to cover all of Canada, But it is complex to import Canvec files in areas were data already exist. Both unexperienced and experienced people may make errors. Import process is often too complex and too long to realize. Micro-tasking presently consist of dividing a a NTS grid area in smaller zones. If this micro-tasking was based on layers, I think that this would reduce the complexity of Canvec imports, reduce errors and encourage more people to import. But if necessary because of size, some NTS grids could be subdivided by smaller zones. The OSM import files would be divided by layers like it is done for planet files. There could be layers such as roads, poi, landuse, water, forest, coastlines, administrative boundaries, other...). This way, the individual import tasks would be less complex to realize, easier to compare with what already exist. Also, the task would be realized more rapidly. When certain type of data such as forests seems less appropriate for a specific area, it would be easy for the mapper to skip this layer. Also, the administrative boundaries and coastlines should be reserved to more experienced people. They could be grouped in a distinct directory and cover larger zones. I think that we need more than the Google doc to monitor the mapping. The New Zealand linz2osm tool seems too complex to me. But it can give us some clue about how to develop such a tool. See linz2osm New Zealand project. http://linz2osm.openstreetmap.org.nz/ See Glen Barnes discussion on Import list. http://web.archiveorange.com/archive/v/2u2n5O1bELI3yg2ULjry Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Internal CanVec conflicts
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] Subject: Re: [Talk-ca] Internal CanVec conflicts I've just performed my first edits, in our neighbourhood. One thing I noticed was that some of the buildings are duplicates. I assume this is part of what you are talking about when you mention internal CanVec conflicts. In the case of a local public school, I deleted one of the copies and dragged the other to match the Bing image. Was that the right thing to do? The internal conflicts are within CanVec itself and of a different type. For example, CanVec might say that the public school is both a school and a forest at the same time. It's hard to say without having seen the area, but what you saw sounds like it's a case of someone not correctly merging CanVec with existing OSM data. When someone imports CanVec they need to make sure it's properly integrated with existing data and not duplicating it. They also need to not blindly replace existing data with imported data. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Internal CanVec conflicts
From: Dan Charrois [mailto:d...@syz.com] Subject: Re: [Talk-ca] Internal CanVec conflicts Usually, in remote areas of the north that I've dealt with, there is often little else already there than the Landsat lakes. And usually, in a given tile, there is usually just a handful of lakes. In pretty much every case I've dealt with so far, I've replaced the Landsat lakes with Canvec data. Landsat lake outlines have a much lower resolution, and being derived by an automatic process themselves, are subject to the errors associated with that. But I wouldn't necessary erase all the Landsat data from a tile without checking first to make sure that there will be Canvec data replacing it (I always work with my Canvec data in a separate layer and merge things in one feature at a time as it's checked). Using Bing imagery may be a good idea to check any issues where Landsat data may exist and Canvec doesn't - even low resolution Bing imagery is usually sufficient for the Landsat lakes. I have yet to encounter a place where there is a Landsat lake and not a corresponding Canvec one of roughly the same shape, but it could happen. I have yet to find a situation where the Landsat lake data is better than the Canvec data. The coastlines in BC were similar and what you have to watch out for is areas where someone has refined the traces but hasn't touched the source tag. I ended up using JOSM to search for nodes that were part of the coastline and were not version 1 nodes from the person who imported the coastline. Even though not all of this stuff was imported from a dedicated account (most of it was done many years ago) it's not too hard to find it with search strings because the importer didn't do anything in the area except for import. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Alaska / BC border
From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: Thursday, November 22, 2012 7:20 PM To: Bruno Remy; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Alaska / BC border You can get the boundary coordinates from the IBC - International Boundary Commission. I also checked with the IBC some time ago and the data is legally okay to use. Me and someone else were working on fixing up the Canada/US border but neither of us was looking at Alaska. I'll post more details on the relevant diary entry (http://www.openstreetmap.org/user/alexz/diary/18102) ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Validating existing data in Ottawa area
Do you know when youll be proposing this import to the various lists? From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: Monday, December 03, 2012 7:55 AM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Validating existing data in Ottawa area Tom For the Québec municipalities administrative boundaries there were discussions on this list about a month ago. We plan to import at once using data from government of Québec. I communicated with the government Données libres site and wait for their approval. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Toronto-area events in early January
I'm going to be in Toronto in the new year and was wondering if any OSM or GIS events, meetings or mappy hours would be taking place. I'll be arriving on the 2nd and leaving on the 7th for Penetang but might be free after that. I'll mainly be spending time with the relatives, but the dates for that are flexible. I'll of course be bringing my GPS + mapping equipment ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Osmose, Outil de qualité, maintenant disponible pour le Québec
Ive been looking at a bot to fix the double-space issue with CanVec/Geobase, but no idea when Ill have the time for it so dont let that stop anyone else interested from developing one, consulting, etc. Serges work in the US with TIGER name expansions might be helpful. Also, just a reminder, if using a tool like osmose, dont blindly accept its suggestions, make sure to review them first. From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] --- Osmose is an error detection tool similar to Keepright. It can detect errors and inconsistencies in OSM data in the form of a map OSM with tooltips. On the left side, we select from the list of problems detected. On the map, the select a tooltip and click to edit directly in JOSM. Starting today, the Osmose tool covers Québec for all error analysis. The rest of Canada is partially covered for some errors but developers of OSM-France tell me that there would be opportunity to include all of Canada. The list of errors is updated daily. see http://osmose.openstreetmap.fr/map/?zoom=10 http://osmose.openstreetmap.fr/map/?zoom=10lat=46.49412lon=-72.81377laye rs=BFFFTitem=level=1,2,3 lat=46.49412lon=-72.81377layers=BFFFTitem=level =1,2,3 Errors list http://wiki.openstreetmap.org/wiki/Osmose/erreurs For some errors detected by Osmose, such as abbreviations or Too many spaces, you will notice when importing in JOSM that the proposed correction is already done in the Name Tag. When you have completed the correction in JOSM you click on the Corrected link of the Osmose tooltip to confirm the correction. Thanks very much to the developers OSM-France for their excellent work. The Statistics section allows us to better coordinate, and see if some adjustments could be corrected automatically by a bot rather than manually. see error table for Québec http://beta.osmose.openstreetmap.fr/errors/?country=canada_quebec As already discussed on the Talk-Ca list, there are a large number of errors that have appeared consistently in previous Canvec imports. We do not find these errors in the recent imports. However, we still need to fix the base OSM for the previous errors. We find in particular: lanes = -1 Names abbreviations and with too many spaces This is an opportunity to make a list of corrections that could be made via a bot. Are there any developers who have the expertise to run a bot and are willing to cooperate? Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OpenDataBC] Call for Speakers @ Open Data BC Summit on Feb 19, 2013 Vancouver
Resenting to the right address... Sent from my iPad On 2013-01-03, at 12:09 PM, Paul Norman penor...@mac.com wrote: I'm considering going to this conference and presenting on OSM use of open data. I figure it might be of interest to a few people as data used by us will be used by Wikipedia, wolfram alpha, MQ open, assorted phone apps, etc... I'm open to other ideas, particularly as I'm on vacation until 2 days before the call for presentations ends. Also if anyone else is interested it makes sense to coordinate. Sent from my iPad Begin forwarded message: From: Nelson Lah nla...@shaw.ca Date: 3 January, 2013 1:26:02 AM EST To: nla...@shaw.ca Subject: [OpenDataBC] Call for Speakers @ Open Data BC Summit on Feb 19, 2013 Vancouver Reply-To: opendat...@googlegroups.com Hi Folks, Now that we have all survived the End of the World, Christmas and New Year, this will be easy... The Open Data Society of BC is hosting the BC Open Data Summit on February 19, 2013 in downtown Vancouver at SFU Segal Graduate School of Business at 500 Granville Street. We are inviting you to be part of this conversation. We're especially proud of what the BC open data community has accomplished over the past three years since we first started growing our community. At the beginning, the thought of accessing data on a government web site was tricky business (imagine wanting access to government data!). We had to sort out challenges around licensing, formats, methods of access...the works. Through many great conversations and threads here and elsewhere, we have thankfully sorted out much of the WHAT of open data. Now that we have some open data accessible to us, we thought it would be helpful to focus on the value that it can bring. We want to explore how it is being used in academia, in evidence-based decision making, in fighting corruption, in uncovering new opportunities, and in creating economic value, businesses and jobs. That's why we're inviting you to join us at the BC Open Data Summit in February. We are calling you to come out and make a short presentation. Share your ideas, and what you or your organization has done with open data to create value. Proposals are due by January 13. More information is available here: http://www.opendatabc.ca/bc-open-data-summit-2013-call-for-speakers.html Many thanks. Nelson Lah Summit Chair on behalf of Open Data Society of BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Fwd: [OSM-talk] (sans objet)
I see that there is an event in Vancouver and some people from the city will be there. I'd like to compile a list of issues with the Vancouver license beforehand. I know rweait had some as blog posts but I think they're offline. Sent from my iPad Begin forwarded message: From: Pierre Béland infosbelas-...@yahoo.fr Date: 9 January, 2013 8:26:10 PM EST To: talk t...@openstreetmap.org Subject: [OSM-talk] (sans objet) Reply-To: Pierre Béland infosbelas-...@yahoo.fr I propose to have discussions that are more fun for all of us than the ones in the last few days. The International Open Data Hackathon on Feb 23 is an opportunity for OSM developpers and mappers to work together and have fun. We could let people better know OSM and licensing problems we face with so called governments, municipalities OpenData not so open. This event is already scheduled in many cities and they ask to propose projects. An OSM project could be proposed for adding data to OSM, exporting from OSM, adapting APIs, etc. see http://wiki.opendataday.org/Main_Page Pierre ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase tags
From: Andrew Allison [mailto:andrew.alli...@teksavvy.com] Subject: [Talk-ca] GeoBase tags Hello: Are the Geobase attribution tags relevant, should I leave them in or strip them out? There's no legal reason why you can't remove the attribution=* tags (or any tag, for that matter). My practice is to remove them when the source=* tag indicates that the source is geobase and I'm editing the way anyways. There may be other import cruft that you want to strip out at the same time. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Licence de données ouvertes, Montréal
It’s good to see more municipalities opening up their data and open data catching on. Seeing more municipalities writing their own licenses isn’t so good. Now, on to the more practical questions needed to use the data. Could you provide a translation of 4.1 and 4.2 of their license? Are these identical to CC BY? One of the problems with CC BY is the vagueness of the attribution. Some cities regard our attribution as not meeting the CC BY attribution requirements, although I guess that isn’t an issue here because they’ve explicitly said it’s compatible with ODbL, so I have to assume that meeting the ODbL attribution requirements (met by listing on http://wiki.openstreetmap.org/wiki/Contributors) is sufficient for them. What’s the Import Workgroup you refer to? Lastly, cadastral data is probably the least exciting type of data for OSM. Other data like roads, addresses and even buildings is more useful. From: Pierre Béland [mailto:pierz...@yahoo.fr] Sent: Saturday, March 02, 2013 9:05 AM To: talk-ca Subject: [Talk-ca] Licence de données ouvertes, Montréal After consultation with the community, the city of Montreal changed its OpenData license the 28 February 2013. It is clearly stated on the page of the license: It is similar to a Creative Commons license CC-BY. For example, it is compatible with the more restrictive type ODbL licenses such as OpenStreetMap. See http://donnees.ville.montreal.qc.ca/licence/ On the Open Data day, Saturday, February 23, representatives of the city have also offered to provide cadastre data. This would greatly contribute to enrich the map of Montreal. If people are interested in contributing to this issue, please contact me. This is a good news for the community of free data, developers and all those who believe in a greater participation of citizens. The city of Montreal, by amending its license, contributes to develop an eco-system where OpenData creators OpenSource developpers, governments and citizens collectively contribute to enrich the information and dialogue. We should of course assure with the Import Workgroup that this license is compatible with OSM. We hope that this example will be followed by others, including the Government of Quebec and Quebec City. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Bing imagery in Montreal
With the new Montreal open data, perhaps they have aerial photography they can release? Or perhaps they already have, but I couldn't find any. If someone can get it, I can host it. From: nicholas ingalls [mailto:nicholas.inga...@gmail.com] Sent: Sunday, March 03, 2013 11:18 AM To: Harald Kliems; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] New Bing imagery in Montreal You are lucky then. Just the other day Saint John area got updated with stuff from late 2012. its great that they are getting around to updating it but the imagery is more oblique than vertical making it very difficult to trace. As well they are really low quality compared to their predecessors. The new ones are faded out where the old ones were sharp and colourful. These look like an instagrammer got at them! ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Licence de données ouvertes, Montréal
From: Harald Kliems [mailto:kli...@gmail.com] Sent: Sunday, March 03, 2013 7:28 AM Subject: Re: [Talk-ca] Licence de données ouvertes, Montréal On Sat, Mar 2, 2013 at 3:58 PM, Paul Norman penor...@mac.com wrote: Lastly, cadastral data is probably the least exciting type of data for OSM. Other data like roads, addresses and even buildings is more useful. Oh, I thought cadastral data would include building outlines? At least that's the case with the somewhat controversial French cadastre imports. Did I get excited prematurely? The exact definition varies, but the generally accepted definition in North America is the zoning, tax or property lot information. It does not include buildings, roads, waterways, sewer infrastructure, etc. It does not generally contain addresses because there is not a one to one relationship between cadastral areas and addresses. I was talking with several people last week about an integrated cadastral fabric for BC. Cadastral information is actually fairly useful as open data, but most people who would want to use it would be forced to get it from the city anyways. There can be some information useful to OSM in it, but generally most of the information is not relevant to us. I tried extracting useful information from Surrey's cadastral layer and found it a lot of work. I did a presentation on open data and OSM to an audience with many open data publishers and I ranked the most useful data as orthophotos, addresses and roads. Orthos because good ones are hard or expensive to get and cities often have excellent ones. Addresses because they're useful for geocoding, annoying to collect manually, and well suited to conflating with existing data. Roads because the road network is generally considered to be one of the most important parts of OSM, so even if the roads are only marginally better than CanVec they can still be useful. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Copyright in data
Thanks for the link. It's good to see a court decision reminding parties that (in Canada) there is no copyright in data. From the court decision: However, there is no principle of property law that would preclude anyone from making use of information displayed in a publicly available paper nautical chart, even if the information originated with the Crown or is maintained by the Crown. It looks like with the summary motion dismissed and the matter going to trial will be what the Crown granted exclusive license to one of the parties in the case. My reading is that if the Crown only licensed the information (one reading of the contract) then the case cannot succeed because the party who initiated the case would of not had exclusive rights as the data does not have any exclusive rights (or any rights) that could be licensed. On the other hand, an alternate reading of the contract is that the Crown licensed the data and CHS Works (paper charts), in which case that party would have had some exclusive rights. Of course this leaves open the question of if those rights were infringed, which gets to an interesting question for OSM because it boils down to distinguishing between data which is not protected by copyright and a map, which may be. From: Begin Daniel [mailto:jfd...@hotmail.com] Sent: Friday, March 22, 2013 4:00 AM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Copyright in data Bonjour all, here is a link here that might be interesting for those of you that are interested in legal matter concerning data http://www.teresascassa.ca/index.php?option=com_k2 http://www.teresascassa.ca/index.php?option=com_k2view=itemid=124:federal -court-of-appeal-reminds-government-there-is-no-copyright-in-data view=itemid=124:federal-court-of-appeal-reminds-government-there-is-no-cop yright-in-data Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] openstreetmap.ca
From: Darryl Shpak [mailto:dar...@shpak.ca] Subject: [Talk-ca] openstreetmap.ca Good morning everyone, So: I am just about to renew this domain for another year. I would like to pass control of the domain over to the Canadian mapping community, to someone who will do something -- anything! -- with it that will be beneficial to Canadian users and/or mappers. I'm running some imagery that I'd of liked to put on openstreetmap.ca. Of course the URLs are all out there now under my personal domain name. I could also host www.openstreetmap.ca, and if we got resources (+someone with cartographic design skills) I could manage a Canadian tile layer. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Question?
This is not correct – there are no mandatory tags, and there is no legal reason why a source tag can’t be removed. Incidentally, source tags are perhaps the ones most frequently removed as osm2pgsql drops them by default. If you’re looking at doing an import http://wiki.openstreetmap.org/wiki/Import/Guidelines is what you need to read. It’s important to note the requirement to consult with both the talk-ca@ and the imports@ mailing lists. This is important because it means if you missed something else someone else might spot it. From: Bruno Remy [mailto:bremy.qc...@gmail.com] Sent: Monday, April 22, 2013 6:55 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Question? * It is mandatory to mention origin and milesim of Opendata, within a tag, for instance Direction générale des finances publiques - année 2008. Source = http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New OpenStreetMap web editing option now available, call for funding
Chances are good that this is a bug with HTTPS anywhere and Firefox. If you are using that extension with Firefox, disable the OpenStreetMap Wiki ruleset. See https://trac.torproject.org/projects/tor/ticket/8841 for the corresponding HTTPS anywhere ruleset bug. From: Stewart Russell [mailto:scr...@gmail.com] Sent: Wednesday, May 08, 2013 5:30 AM To: talk-ca Subject: Re: [Talk-ca] New OpenStreetMap web editing option now available, call for funding On Tue, May 7, 2013 at 3:48 PM, Fabian Rodriguez magic...@member.fsf.org wrote: http://blog.openstreetmap.org/2013/05/07/openstreetmap-launches-all-new-easy -map-editor-and-announces-funding-appeal/ All I get is a blank white screen with iD on Firefox 20.0.1 (aka current release). That might be a bit of a hurdle for new editors ... Stewart ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Advice on Addressing
Individual addresses are always preferable to interpolation lines, interpolation lines are just an approximation so if you have all the addresses in a block you shouldn't also have interpolation lines as the latter duplicates the former. As for how to tag the addresses, if they're buildings with only one address I prefer put the addresses on the buildings. For more complicated situations with multiple addresses per building you'll often end up with points for addresses, and these points often also have shop information. From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: Monday, May 27, 2013 6:48 AM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Advice on Addressing Hello, With respect to Nominatim and OSM routing applications is there are better way to add address data to OSM? I have started adding some address data in my neighborhood but I am wondering if tagging buildings with an address is better or worse than digitizing address interpolation lines? http://www.openstreetmap.org/?lat=45.90249493718147 http://www.openstreetmap.org/?lat=45.90249493718147lon=-66.69308423995972; zoom=18 lon=-66.69308423995972zoom=18 Thanks, Bernie ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Open Government Licence - Canada
From: Stewart C. Russell [mailto:scr...@gmail.com] Subject: [Talk-ca] Open Government Licence - Canada [I guess Bernie's original subject of ‘G8 leaders sign open data charter of principles’ might've made this important announcement sink without trace.] Bernie Connors wrote: Is there an official OSM opinion on the compatibility of the Open Government Licence and OpenStreetMap? Here is a link to the licence on the data.gc.ca website – http://www.data.gc.ca/eng/open-government-licence-canada It would be very helpful if it were deemed acceptable. The somewhat damp few who made it out to the Toronto Mappy Hour last night discussed it, but couldn't come up with anything official. The good: It's very similar to the OGL, which is compatible. This should minimize the analysis. The bad: It's only somewhat similar, leading to yet another regional license to analyze. The ugly: They put terms specific to the federal government in the license and expect every city and province to modify the license. This is going to not work well. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Kelowna Open Data
I don't know how this slipped under my radar, but Kelowna BC has open data, licensed under the PDDL. I see that they have 2012 aerial photos, which I'll work on hosting, although I might need to upgrade my server first. What's more interesting is they have some address data. If there is a local desire I could look at doing something with this. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Open Government Licence
From: Steve Singer [mailto:st...@ssinger.info] Cc: 'Matthew Buchanan'; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Open Government Licence Wouldn't the multiple Information Providers kick is as soon as you combined data from Vancouver with any other source such as the existing OSM database? No. OpenStreetMap is not The City of Vancouver and therefore not an Information Provider as defined in the license. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Lake Erie shores
I happened across http://www.openstreetmap.org/browse/relation/1205150, a relation with name=Lake Erie. My recollection is that last time this came up we decided that as the Great Lakes are large lakes by any reasonable standard they are best represented as natural=coastline. Thousand-member MPs simply do not work. Right now they are both a natural=water MP and natural=coastline ways. Unless anyone recalls differently I'll go ahead and verify that the coastline is building correctly then clean up the MPs. I'm pretty sure the coastline is building as if it weren't we wouldn't see the great lakes at low zooms I'll also clean up stuff like 1205139. See http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Aerial imagery for Nanaimo, BC
License issues seem to expand to fill my available time. Nanaimos license is different than the OGL (a UK license) in a few ways. I dont think anyone has analyzed it for ODbL compatibility. One minor mistake that was made was defining an Information Provider solely as The City of Nanaimo, unlike the original OGL which defined it as the person or organization. Thats the biggest issue Im aware of with it, but I believe when publishing open data under a self-developed license the onus should be on the on the publisher to consider compatibility with other licenses. After all what good is open data if you cant combine it with existing data sets. There are one or two datasets I would love to use immediately and a few more I would like to use when I get the time to sit down and do some work, but both are on hold because Im not certain if their license is ODbL compatible. It would be helpful if the publisher of the data or the license (The City of Nanaimo) made a statement on the compatibility of their license with the OGL. Itd also be useful to know about CC BY/CC BY-SA compatibility, but that isnt necessary for use with OSM. From: Tim Whitehead [mailto:spero.shirope...@gmail.com] Sent: Sunday, October 20, 2013 4:55 PM To: 'David E. Nelson' Cc: 'Paul Norman'; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aerial imagery for Nanaimo, BC I am no legal person by any means, and Nanaimo has adopted v2 of the OGL since I last looked at it. Paul Norman mentioned he was going to look into it when there was a moment to do so. The way I read v2 of the license is that it is available to use so long as you acknowledge the source with the defined attribution statement of the region. Contains information licensed under the Open Government Licence - Nanaimo. If multiple sources were used or multiple attributions are not practical, one would use Contains information licensed under the Open Government License British Columbia. http://www.nanaimo.ca/EN/main/departments/106/DataCatalogue/Licence.html http://www.data.gov.bc.ca/local/dbc/docs/license/OGL-vbc2.0.pdf Though it looks like they missed updating the last paragraph under Versioning. To answer your actual question though, nope I am not aware of another WMS source J Cheers, Tim From: David E. Nelson [mailto:denelso...@yahoo.ca] Sent: October 20, 2013 4:12 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Aerial imagery for Nanaimo, BC Does anyone know of an OSM-compatible free WMS source we can use for aerial imagery for all of Nanaimo? Bing does not have street-level imagery for Nanaimo north of 49.14°N and east of 123.94°W ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Aerial imagery for Nanaimo, BC
We seem to be jumping ahead a bit quickly. We haven’t solved the legal issues about using any of their data, so it seems premature to be worried about the technical details. Once the legal issues get cleared up I can easily take the Nanaimo imagery and host an imagery layer which can be added to the defaults of the editors, making it available for all. From: Tim Whitehead [mailto:spero.shirope...@gmail.com] Sent: Sunday, October 20, 2013 6:58 PM To: 'David E. Nelson' Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aerial imagery for Nanaimo, BC There is also an Opendata plugin that can be added for some of the formats I am not familiar with all the formats available – Shape (SHP), Keyhole (KML) can be opened directly in the achieve they are downloaded in– I would create a new layer first, and it’ll prompt you for what you want to open (I,e, road centre lines, sidewalks, etc). http://wiki.openstreetmap.org/wiki/Import/Shapefile http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData If you wanted to use the tiff file… I do not believe they supply a world file in the achieve so you would need something like the Piclayer plugin (I believe) From: David E. Nelson [mailto:denelso...@yahoo.ca] Sent: October 20, 2013 6:08 PM To: Tim Whitehead; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aerial imagery for Nanaimo, BC Could get that from their data source? http://www.nanaimo.ca/EN/main/departments/Engineering-Public-Works/GIS/Digi http://www.nanaimo.ca/EN/main/departments/Engineering-Public-Works/GIS/Digit alData.html http://data.nanaimo.ca/ http://data.nanaimo.ca/ http://www.nanaimo.ca/ortho/ http://www.nanaimo.ca/ortho/ (553A) Building/Properties/Road ways are available and can be overlayed in JOSM. And how do I do that? How do I import that data, both ways and photos, into JOSM? - David E. Nelson attachment: winmail.dat___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Do we tag addresses on buildings or on separate nodes?
Interpolations are generally regarded as approximations until we can get individual addresses mapped. The post in case was about if was more common to map a building with an address as one way with a building tag and address tags or as one way with a building tag and a node with address tags. It is more common to use a way with both a building tag and address tags by at least 10:3. From: Bruno Remy [mailto:bremy.qc...@gmail.com] Sent: Thursday, October 24, 2013 7:34 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Do we tag addresses on buildings or on separate nodes? Hi, What do you think of this blog? Adress nodes versus interpolations? That's quite confusing :-/ What is the OpenStreetMap convention? Do we tag addresses on buildings or on separate nodes? http://t.co/tjRiwYSXLF Bruno ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Open Government License - Canada
cc'ing to a few people who I have talked about this with in the past. Some governments in Canada have released data under the Open Government Licence - Canada, version 2.0. This is yet another new license. Some people have asked if we can use datasets available under this license. http://data.gc.ca/eng/open-government-licence-canada contains the full text of the version the Federal government is using. It is an attribution license and in a perfect world would be ODbL compatible. Of course we've seen plenty of attribution licenses screw something or other up. What is not obvious is that they expect other levels to modify the license to localize it with the information of their attribution statement and local laws, but let's start with the Federal one first. Once that's done we can look at BC, AB, Nanaimo, Vancouver... etc. One of the statements in the consultation on this license was The change of the attribution statement from OGL v1.0 to be one specific to the federal government reduces the ability to reuse this license by other jurisdictions (e.g. provinces) and will increase the number of licenses that have to be analysed. The origin of this license is the OGL 1.0, a UK license. The principle difference between UK and Canadian law is that database right does not exist in Canada. http://opendefinition.org/licenses/ lists OGL Canada 2.0 as an Open Definition conformant license. The question that matters for OSM is, can OGL Canada 2.0 datasets be released under the ODbL. One issue raised as problematic in some versions of the license is Personal Information For OSM, I do not see this as an issue. Personal Information is information about an identifiable individual, but datasets we would be interested in are information about places, not individuals. Third-party rights are a rights-clearing issue and something we'll need to check before using any source. Names, crests, etc and other IP rights would not be found in datasets of interest to OSM. Attribution is an odd one because they refer to information providers in the plural, but define it in a way so that it is only singular, so it's not clear which part of the attribution requirements applies. The ODbL requires that any copyright notices be kept intact for derivative databases. Produced works require a notice reasonably calculated to make any Person [...] aware that the content was obtained from [the database]. Attribution looks ODbL compatible, provided we figure out what statement to use. I'm not really sure where to take it from here in terms of an analysis. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec 10 Data
I don't believe CanVec has any addressing info in metro Vancouver, so no conflict there. I'd also hope that if people regard addresses as important they've been collecting them in surveys when out mapping, so there are address already there that should *not* generally be replaced by CanVec data. From: Steve Roy [mailto:st...@ssni.ca] Subject: Re: [Talk-ca] CanVec 10 Data Agreed. I see that Paul Norman imported some of the City of Surrey GIS data a couple of years ago and that included house numbers. Cheers Steve On 04/11/2013 6:16 AM, Harald Kliems wrote: I think Daniel's email got cut off at the end :-) On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin jfd...@hotmail.com mailto:jfd...@hotmail.com wrote: I'm not familiar with imports using Potlatch but importing it using JOSM is quite easy - open the file, select the features, copy then in a new layer and then upload the layer in OSM... ...after you've carefully checked if everything is plausible and you don't mess up the work of other contributors who may already have added housenumber data of better quality. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-legal-talk] Open Government License - Canada
I got word back indicating that the OGL - Canada 2.0 is ODbL and CC BY compatible. This makes it easy for us to use. I want to offer my profound thanks to the federal government and the people I talked to in it for being willing to answer questions about licensing. -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Sunday, November 03, 2013 8:29 PM To: 'Licensing and other legal discussions.' Cc: 'Levene, Mark'; 'David E. Nelson'; talk-ca@openstreetmap.org Subject: [OSM-legal-talk] Open Government License - Canada cc'ing to a few people who I have talked about this with in the past. Some governments in Canada have released data under the Open Government Licence - Canada, version 2.0. This is yet another new license. Some people have asked if we can use datasets available under this license. http://data.gc.ca/eng/open-government-licence-canada contains the full text of the version the Federal government is using. It is an attribution license and in a perfect world would be ODbL compatible. Of course we've seen plenty of attribution licenses screw something or other up. What is not obvious is that they expect other levels to modify the license to localize it with the information of their attribution statement and local laws, but let's start with the Federal one first. Once that's done we can look at BC, AB, Nanaimo, Vancouver... etc. One of the statements in the consultation on this license was The change of the attribution statement from OGL v1.0 to be one specific to the federal government reduces the ability to reuse this license by other jurisdictions (e.g. provinces) and will increase the number of licenses that have to be analysed. The origin of this license is the OGL 1.0, a UK license. The principle difference between UK and Canadian law is that database right does not exist in Canada. http://opendefinition.org/licenses/ lists OGL Canada 2.0 as an Open Definition conformant license. The question that matters for OSM is, can OGL Canada 2.0 datasets be released under the ODbL. One issue raised as problematic in some versions of the license is Personal Information For OSM, I do not see this as an issue. Personal Information is information about an identifiable individual, but datasets we would be interested in are information about places, not individuals. Third-party rights are a rights-clearing issue and something we'll need to check before using any source. Names, crests, etc and other IP rights would not be found in datasets of interest to OSM. Attribution is an odd one because they refer to information providers in the plural, but define it in a way so that it is only singular, so it's not clear which part of the attribution requirements applies. The ODbL requires that any copyright notices be kept intact for derivative databases. Produced works require a notice reasonably calculated to make any Person [...] aware that the content was obtained from [the database]. Attribution looks ODbL compatible, provided we figure out what statement to use. I'm not really sure where to take it from here in terms of an analysis. ___ legal-talk mailing list legal-t...@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Making use of Kelowna open data
I've been setting up a new server and setting up new imagery and other resources for the OSM community. One that's basically finished is some stuff making use of the City of Kelowna data, published under the PDDL. I've put up a page demoing what I've done at http://tile.paulnorman.ca/kelowna.html. I have an overlay generated from the city road and lanes data and imagery also from the city. A close-up example is http://tile.paulnorman.ca/kelowna.html#20/49.8873/-119.4972. You can switch to an OpenStreetMap background, although this only goes to zoom 19. The road names are in caps because that's how the data comes. I'll be adding these layers to the editors soon, once I make certain everything is stable and make a few setup tweaks. Along those lines, don't be too surprised if there are intermittent issues while I get everything setup! I'm also thinking of asking Firefishy to point tile.openstreetmap.ca at the host because I plan on putting a number of Canadian layers there. I know there is some desire for the City of Nanaimo imagery and other imagery licensed under OGL variants, but until we figure out if their licenses are compatible with the ODbL I'm holding off because we can't use them with OpenStreetMap yet. Technical details: The imagery is an ECW file, served and cached with mapproxy in front of mapserver. The overlay data is downloaded and imported into postgresql with a script, cleaned up in postgres, and then served and cached with mapproxy and rendered with mapnik. The relevant scripts are at https://github.com/osm-ca/road-overlay-scripts and https://github.com/osm-ca/mapproxy-config-faramir. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Problem with overpasses in NB??
From: Daniel Begin [mailto:jfd...@hotmail.com] Sent: Monday, December 02, 2013 1:34 PM To: 'Richard Weait'; 'Connors, Bernie (SNB)' Cc: 'Talk-CA OpenStreetMap' Subject: Re: [Talk-ca] Problem with overpasses in NB?? Provinces provide roads to NRCan that simply package it for GeoBase and Canvec. I might be wrong but I am on the impression that some provinces (not all) create vertices at intersections (2D) and do not consider the elevation (3D). When converting to OSM, duplicated vertices (one on each road) are merged in one node. The problem is often one of formats. Shapefiles are often used to interchange this data, but shapefiles do not have topology. A common toolchain used for getting data from an ESRI-based server to shapefiles results in files that say that wherever two features cross they join. This is the type of mistake that someone doing an import needs to catch and fix before uploading. The fastest fix I've found in JOSM is to merge the two bridge ways, merge the two under-bridge ways, and delete the node where they intersect. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Nanaimo OGL license
Previously[1] I looked at the OGL - Canada 2.0. The federal government opinion is that the license is compatible with the ODbL and CC BY. The OKFN regards the OGL - Canada 2.0 as meeting the Open Definition. The OGL - British Columbia and OGL - Nanaimo are different licenses. Aside from formatting, branding and jurisdictional differences, the two significant changes are the addition of an exemption, and defining Information to include Records[2]. The exception is to not license Information or Records not accessible under the Freedom of Information and Protection of Privacy Act (B.C.) [(FIPPA)] Although it has not come up for a vote, the view on the Open Definition mailing lists[3] is that this exemption makes the license non-open because it is impossible or impractical for a user to know if the license is applied to a particular work, or if it falls under one of the exemptions. The vagueness comes from two sources: difficulty in interpreting what is meant in the license, and difficulty evaluating if a particular work falls under a FIPPA exemption. I have more information about the possible interpretations of this phrase and different types of FIPPA exemptions, but see no need to go into that at this time. If it were not for this exemption, I do not see anything that would cause its ODbL compatibility to differ from the OGL - Canada 2.0. Fortunately, there is a way around the vagueness of the exemption: to find out the FOI status explicitly. I asked the City of Nanaimo about the orthophotos, addressing and roads data and their FOI officer informed me that I may treat those datasets as released 'in accordance with the Provincial Freedom of Information and Protection of Privacy Act'. This does NOT apply to all Nanaimo datasets, nor to other datasets released by other cities under similar licenses. I would *expect* all datasets on data catalogue sites in BC to be released in accordance with FIPPA, but I believe it is necessary to verify this. I have no import-related plans at this time for the addressing or roads data, but I've had multiple requests to make the orthophotos available as a background for editing, as they are significantly better than Bing. I may do an overlay with the roads data, similar to the TIGER 2013 overlay, or what I did for Kelowna[4]. Kelowna's data is under the PDDL, which made it legally much easier to work with. The effort involved in verifying that a license used only by one city is usable shows how custom licenses significantly increase the work for data consumers (e.g. OpenStreetMap), particularly if multiple data sources are involved. It would be significantly easier if the data was released following best practices and used an established license such as, in order of preference: CC0, PDDL, CC BY 4.0, or ODC-BY. [1]: https://lists.openstreetmap.org/pipermail/legal-talk/2013-November/007668.ht ml [2]: https://gist.github.com/pnorman/7716944 [3]: https://lists.okfn.org/pipermail/od-discuss/2013-October/000633.html [4]: http://tile.paulnorman.ca/demo/kelowna.html ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Parc Summit Montréal
Both landuse=forest and natural=wood may be used to indicate an area with trees. There are differing views about what the tags mean, so it is possible for one person to sensibly use landuse=forest to map something while a different person would use natural=wood to map that exact same thing. From: Adam Martin [mailto:s.adam.mar...@gmail.com] Sent: Friday, January 10, 2014 11:19 AM To: Simon Mercier Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Parc Summit Montréal Bonjour Simon! Forgive my lack of ability in writing french - hopefully it won't make a difference. Took a look at the area that you are referring to. The area that is designated as the park is a Forest while the other overlapping area is designated as Wood. From looking over the maps provided by the City of Montreal (http://www.lemontroyal.qc.ca/carte/en/index.sn), it would appear that the overlap is incidental - the park area includes much of the green space boxed in by the road and administrative boundary, but not all of it. In fact, the park is separated from the administrative boundary by a small gap. It appears that it should actually be connected to that boundary. The use of Forest is odd - this is a designated park and would likely be better suited to be noted as amenity=park. It is arguable that Forest is not the predominate use for the area as that tag tends to be used for areas that are managed by humans for the purposes of harvesting. Is having the landuse here actually necessary? Using the amenity tag for a park appears to override the Forest tag with the actual use of the land (for recreational purposes). Hope that helps. Adam 2014/1/10 Simon Mercier smerc...@mapgears.com Bonjour Je me demande s'il s'agit d'une erreur ou simplement circonstanciel? Est-ce qu'il s'agit pour un d'une limite administrative de parc (20187021) et l'autre de la forêt(189610345)?Ça me semble tout de même ambigu! http://www.openstreetmap.org/way/189610345 http://www.openstreetmap.org/way/20187021 merci -- simon mercier co-fondateur solutions mapgears 2383 che ste-Foy bur 202 québec, qc canada G1V1T1 t_418_476_7139#101 m_418_559_7139 simonmercier.net / mapgears.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] GNS tag cleanup
About 6 years ago, a set of data was imported from GNS, consisting of place names, mainly of place=town. As an example, see http://www.openstreetmap.org/node/52556192/history Thy have a few tags, many of which can probably be safely automatically eliminated by editor software. Using the example node, I think the following should be added to the automatic removal list in editors gns:dms_lat=490200 gns:dms_long=-1224900 gns:lat=49.03 gns:long=-122.816667 gns:n:xx:full_name=White Rock gns:n:xx:full_name_nd=White Rock gns:n:xx:modify_date=1993-12-14 gns:n:xx:sort_name=WHITEROCK gns:cc1=CA I'm not sure on the following. Anyone know their history, and if they're of any use to OSM? gns:adm1=02 gns:dsg=PPL gns:fc=P gns:jog=NM10-08 gns:mgrs=10UEV1340031177 gns:n:xx:nt=N gns:rc=1 gns:ufi=-575923 gns:uni=-812858 Any comments? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec updates without a version bump
I was having a look at New Westminster in tile 092G02.1.1, and I noticed that there are differences between CanVec 10.0 which I downloaded when it came out and what I just downloaded from the CanVec webpage, which is also labeled CanVec 10.0 Addresses have been added, and with them, errors introduced. Although I'm not opposed to adding addresses, adding a new feature like this obviously needs discussion and review, and I checked imports@ and it doesn't look like this happened. Who's our contact at NRCan these days? We need to make sure that the scope of what's getting imported is clear and that additions get properly discussed. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
From: Daniel Friesen [mailto:dan...@nadir-seen-fire.com] Sent: Wednesday, February 19, 2014 3:10 AM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Updating Langley and use of alt_name? I'm a little new to OSM, recently I found that neither of the city boundaries for the Langley area showed up in searches for Langley. The issue was that neither had any type of name entry with just Langley I added an alt_name=Langley to both of the boundaries myself: http://www.openstreetmap.org/relation/2031946 (City of Langley) http://www.openstreetmap.org/relation/2031947 (Township of Langley) I think it's reasonable. Langley could refer to either, but it's not the official name of either, or the less formal name they commonly use. alt_name sounds suitable. For those who aren't local - Both the City and Township are incorporated municipalities in local terms, which maps to admin_level=8 - They are adjacent, but do not intersect, nor are they within each other. - The Township is much larger, and has open data. The City is smaller, and has GIS department consisting of one person. - There is often no distinction between the two, and their addresses are on a grid layout That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. However, I'm not sure that its place=town node can be tied solely to the admin relation for one or the other. I'm not sure what to do, but one suggestion was to put it as the label of both. Label is a bit of a misnomer really - the only current function of it is to Indicate that the place node and admin boundary somewhat refer to the same thing. It is not used by the standard stylesheet for rendering of administrative boundary labels, nor are there plans for it to be (https://github.com/gravitystorm/openstreetmap-carto/issues/105) ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
No one has raised the issue on legal-talk@ since CC 4 was released. From: Pierre Béland [mailto:pierz...@yahoo.fr] Sent: Thursday, February 20, 2014 8:43 AM To: diane.merc...@gmail.com; Talk-ca (OSM) Subject: Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-legal-talk] Nouvelle licence de données ouvertes au Québec
CC BY 3.0 and earlier had onerous attribution requirements for data. I believe 4.0 fixes this. I don't think anyone has suggested contacting a data provider who's licensed under CC 4.0 licenses to clarify attribution. The issue with 3.0 attribution are not purely theoretical, there have been providers who have objected to how we have attribution and we've been unable to use their data. Sent from my iPad On Feb 21, 2014, at 1:58 PM, Mike Linksvayer m...@gondwanaland.com wrote: Asking for a clarification that provided attribution is OK seems over the top too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the [attribution conditions] in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. If every attribution needs to be clarified with the licensor to determine if it is OK, then attribution licenses truly are a fail. But that practice is certainly not the intent of such licenses. IMO, IANAL, etc etc. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
From: William Rieck [mailto:bi...@thinkers.org] Sent: Friday, February 21, 2014 9:10 AM Subject: Re: [Talk-ca] Updating Langley and use of alt_name? Hi Paul, I was following your message until this statement, where I got confused. Are you saying the city of Langley is not a city? What do you mean by in British English? That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. British English, as opposed to Canadian English or American English. OSM uses British English Using a simpler example, Burnaby does not meet the British English definition of a city, but Vancouver does. Burnaby is a town. An incorporated area is not necessarily a city. http://www.dict.org/bin/Dict?Form=Dict2Database=wnQuery=city includes two definitions of city: n 1: a large and densely populated urban area; may include several independent administrative districts; Ancient Troy was a great city [syn: city, metropolis, urban center] 2: an incorporated administrative district established by state charter; the city raised the tax rate OSM is closer to the first definition. Historically a city was the see of a bishop, but that no longer holds. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
Ive added the place node to both relations after discussions with Nominatim experts. Its a bit strange, but so is the situation. It seems to fix the queries you gave. From: Pierre Béland [mailto:pierz...@yahoo.fr] Sent: Friday, February 21, 2014 7:52 PM To: Pierre Béland; William Rieck; Paul Norman Cc: talk-ca Subject: Re: [Talk-ca] Updating Langley and use of alt_name? Oups I was wrong in identifiying the polygons in JOSM. These are two adjacent polygons, the city being surrounded by the township. The difference in spelling comes from the alt_name=Langley. I should have mapped for the Night of the living map instead. Or maybe not! Pierre _ De : Pierre Béland pierz...@yahoo.fr À : William Rieck bi...@thinkers.org; Paul Norman penor...@mac.com Cc : talk-ca talk-ca@openstreetmap.org Envoyé le : Vendredi 21 février 2014 21h53 Objet : Re: [Talk-ca] Updating Langley and use of alt_name? Looking at the Township and City of Langley, I see that these relations are duplicate polygons that share the exact same nodes. Then why two relations? Instead, would it be better to simply use alt_name for the city, added to the Township of Langley. Such Classification where you have two admin_level=8 for the same area is a nonsense to my point of view. To show the inconsistencies that this creates, let's have a look at the Nominatim links below. You will see how the Locality, Suburb, Residential highways etc. are shared between the two. And most of the item are classified under the Township. Some other elements under the City. But searching Nominatims, you will see places classified either und the Township, the City of simply Langley. For example, if you search in Nominatim for * Livingstone, Langley. Canada, this will be reported as Livingstone, Township of Langley, Greater Vancouver Regional District, British-Columbia, Canada * 10 Avenue, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * Brookswood, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * 201A Street, Brookswood, Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada The best seems to make a choice for which locality title will be showed to describe Langley and use an alt_name tag to describe the second appellation * City Boundary Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031947 http://www.openstreetmap.org/relation/2031947 http://nominatim.openstreetmap.org/details.php?place_id=9164399767 * City Boundary City of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031946 http://www.openstreetmap.org/relation/2031946 http://nominatim.openstreetmap.org/details.php?place_id=98083231 Pierre _ De : William Rieck bi...@thinkers.org À : Paul Norman penor...@mac.com Cc : talk-ca talk-ca@openstreetmap.org Envoyé le : Vendredi 21 février 2014 12h09 Objet : Re: [Talk-ca] Updating Langley and use of alt_name? Hi Paul, I was following your message until this statement, where I got confused. Are you saying the city of Langley is not a city? What do you mean by in British English? That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: workflow for elevation data
From: Richard Weait rich...@weait.com Date: Sun, Feb 23, 2014 at 4:40 PM Subject: Re: [Talk-ca] workflow for elevation data To: Charles Basenga Kiyanda perso...@charleskiyanda.com There was a service, run by long time OpenStreetMap user lambertus, that displayed an elevation profile graph of a selected way. That specific source is gone or moved now, but this wiki page shows some of the similar details from a related summer of code project. http://wiki.openstreetmap.org/wiki/Route_altitude_profiles_SRTM It also appears that the routing engine YOURS can interpret elevation data to apply variable costing when evaluating or planning routes. http://wiki.openstreetmap.org/wiki/YOURS OSRM can also use elevation data when planning routes. For an example of this, including elevation profiles try http://cycle.travel/map, generate a route, and click on the mountain icon to get a profile. Unfortunately cycle.travel is UK only. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] coastline between Montreal and Sorel, Quebec
From: perso...@charleskiyanda.com [mailto:perso...@charleskiyanda.com] Sent: Thursday, April 03, 2014 9:27 AM To: Harald Kliems Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] coastline between Montreal and Sorel, Quebec The question of where does the coastline end and riverbank start is a question that was probably debated at length 4-5 years ago with no clear resolution. The page does mention the great lakes as an example of lakes wrongly tagged with coastline, but that will probably stay like that in the near future. Personally, I think the great lakes should stay as coastline not just because it'd be hard to change. It might be worth coming to a consensus here first before we try to fix the coastline between Montréal and Sorel. Clearly, the current situation is suboptimal. Last time the Great Lakes were discussed, the consensus was that they, along with a few substantial water bodies, should be tagged with natural=coastline. This isn't a question of rendering, it's a question of data modelling. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Adding a trail to OSM that is also a road
You’re best off tagging the road (highway=track probably, maybe highway=unclassified) and indicating that it’s part of the Trans Canada Trail with a relation. From: Brian Lang [mailto:bril...@gmail.com] Sent: Sunday, April 20, 2014 9:15 PM To: Richard Weait Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Adding a trail to OSM that is also a road In this case, the road is a Forest Service Road - often meaning low quality road, infrequent maintenance, lots of potholes and creeks running over the road. 4x4 recommended but in this particular case not required. I have both hiked and driven this section of road. The Trans Canada Trail IS the road. I was thinking it might be best to put a parallel set of lines for the Trans Canada Trail due to the fact that the road is not always open to vehicles. But as I'm new to using OSM, I figured I'd ask first. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Local Vancouver meeting: Map Central Park
I am planning on hosting a mapping event in Central Park (http://osm.org/way/23165846), in Burnaby, BC. My tentative date is Sunday, June 15th at around noon, but if people want a different time I could shift it. The park is a major park in the region, but under-mapped, with potentially not all of the trails. Some of the things I'd like to get mapped are - More appropriate tags for the trails. highway=track is probably not accurate - The surface of trails - Locations of fitness equipment in the park - Bathrooms - Picnic areas - Other park infrastructure - Anything missing or interesting At this time of year, it should be nice sunny weather, and the shade from the trees should be welcome. I intend to bring my mapping kit (camera, GPS, etc), as well as field papers type printouts on larger paper for us to mark up. I'm not planning on bringing a laptop, or if I do, it's staying in the trunk. After mapping, we can go somewhere nearby for food. I'd also like to discuss holding regular events. If you're interested, please let me know so that I know other people will be coming and to attend on time myself! I also need to have printouts made in advance. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Local Vancouver meeting
Yes - change of date. June 14th, noon. I completely forgot about Father's day, which also causes difficulties for me. On 2014-06-04 8:35 PM, B P Chin wrote: Hi Paul, June 15 is Father's Day. Any chance that you could this to another date? I would love to take part in this. Peter From: talk-ca-requ...@openstreetmap.org Subject: Talk-ca Digest, Vol 76, Issue 2 To: talk-ca@openstreetmap.org Date: Wed, 4 Jun 2014 12:00:02 + Send Talk-ca mailing list submissions to talk-ca@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-ca or, via email, send a message with subject or body 'help' to talk-ca-requ...@openstreetmap.org You can reach the person managing the list at talk-ca-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-ca digest... Today's Topics: 1. Re: Local Vancouver meeting: Map Central Park (Clifford Snow) -- Message: 1 Date: Tue, 3 Jun 2014 09:53:03 -0700 From: Clifford Snow cliff...@snowandsnow.us To: Paul Norman penor...@mac.com Cc: talk-ca talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Local Vancouver meeting: Map Central Park Message-ID: cadaoplpofv6u2-zsq2n_i0pplrvngcdjstckfa6zuw6wzpb...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Paul, Thanks for scheduling the mapping party. I plan to attend along with one guest. I'll bring my GPS along with my Android phone with OSMTracker. Clifford On Tue, Jun 3, 2014 at 2:36 AM, Paul Norman penor...@mac.com wrote: I am planning on hosting a mapping event in Central Park ( http://osm.org/way/23165846), in Burnaby, BC. My tentative date is Sunday, June 15th at around noon, but if people want a different time I could shift it. The park is a major park in the region, but under-mapped, with potentially not all of the trails. Some of the things I'd like to get mapped are - More appropriate tags for the trails. highway=track is probably not accurate - The surface of trails - Locations of fitness equipment in the park - Bathrooms - Picnic areas - Other park infrastructure - Anything missing or interesting At this time of year, it should be nice sunny weather, and the shade from the trees should be welcome. I intend to bring my mapping kit (camera, GPS, etc), as well as field papers type printouts on larger paper for us to mark up. I'm not planning on bringing a laptop, or if I do, it's staying in the trunk. After mapping, we can go somewhere nearby for food. I'd also like to discuss holding regular events. If you're interested, please let me know so that I know other people will be coming and to attend on time myself! I also need to have printouts made in advance. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20140603/1c3e6e04/attachment-0001.html -- ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca End of Talk-ca Digest, Vol 76, Issue 2 ** ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canadian OSM POI quality
I was curious how complete OpenStreetMap shop data was, so decided to do an analysis for some Canadian chains. The results were mixed. Starting with a Canada extract, I processed the data into PostGIS and ran queries against name, brand and franchise for objects where amenity, office or shop was null. Brands which have recently changed names (e.g. Zellers/Target) were avoided. OSM completeness varied from 7% to 81%, with no overwhelming trends. The four major fast food and restaurants chains considered ranged from 33% to 51%. Shops opening and closing change the accuracy of these results, and the accuracy of the external sources for number of shops may be variable. Method == The geofabrik extract for Canada was imported with osm2pgsql with a custom .style file containing name, operator, brand, franchise, amenity, building, office and shop columns. The last four columns caused an object to be placed in the polygon table. After import, the tables were filtered to remove rows where there was not an amenity, office, or shop tag. Appropriate indexes were added. A view was created combining the two tables and giving lower-case versions of the name, operator, brand and franchise tags. Queries of the following form were run SELECT COUNT(*) FROM shops WHERE lname LIKE :'name' OR lbrand LIKE :'name' OR lfranchise LIKE :'name'; :'name' was substituted in by psql for what I was searching for. For example, 'mcdonald%' for McDonald's. The queries used were intended to catch all possible shops even if it resulted in false positives. Brand selection was not done in any systematic manner. Public sources were used for the true number of shops of a particular chain, generally Wikipedia or public data aggregators. Results === OSM True Completenmess Tim Horton's 1480 4304 34% Subway 849 2563 33% McDonalds 722 1417 51% Starbucks 592 1363 43% Both OSM and Google use both Starbucks and Starbucks Coffee A W 292800 37% Domino's67383 17% Wendy's224369 61% Burger King150281 53% East Side Mario's 46 85 54% Milestones 32 44 73% Chili's 10 16 63% Sears 105 15707% Rona 122500 24% The Bay 50421 12% Walmart265382 69% Home Depot 95180 53% Canadian Tire 400491 81% May be double-counting automative centers. Chapters47233 20% Sleep Country 22179 12% London Drugs54 78 69% May be double-counting some stores with a pharmacy inside Remarks === It took significantly longer to find the true number of stores than to get results from the OSM data. Part of this is my increased familiarity with OSM tools, but a large part is that it is not necessary to track down many different sources to get store counts. Although no urban/rural analysis was performed, it is generally expected that OSM is more complete in populated urban areas than low-density rural areas, and completeness in these urban areas are often more important for many uses. No proprietary data sources were available for comparison, but it should not be assumed that they are any more complete, nor that their name or similar tagging is any more consistent. As an example, Google's data was observed to use both Starbucks and Starbucks Coffee for the coffee chain, sometimes having both for what was really the same location. The tools used to generate counts could easily be used to extract the shop data to work with. Improving the data == Inconsistent tagging was observed with some shops, such as variability between amenity=restaurant and amenity=fast_food. This should reflect differences between locations but may not. Inconsistent names were also observed, such as Walmart, Wal-mart, and Wal Mart. These issues are not as significant as the large percentage of missing shops. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Central Park meetup: lot full
The parking lot at swangard stadium is full for an event. Parking lot off of boundary nearest, marked for pool/stadium. Call 604 7792432 if needed. Wearing high vis osm vest Sent from my iPhone ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Mapillary coverage in Vancouver
For some time I have been taking pictures to map from, and now that Mapillary is out, I finally have a way to share them. Mapillary is a company that is making a service similar to the old OpenStreetView, where they collect pictures of roads. The difference is that they currently offer the pictures under an open license, CC BY-SA, and they have given explicit permission to derive information for OpenStreetMap. They have a clever app, but what matters for me is that I can upload the pictures from my car-mounted camera after geotagging them. As I drive a reasonable distance and I've designed my setup for capturing images for mapping from, this means that the Mapillary coverage is building up in Greater Vancouver with excellent images for OSM use. The only problem is I have been unable to keep up with the rate I've been taking pictures. This means there's a lot of information in Mapillary pictures that can be entered into OSM. You can see the coverage at http://www.mapillary.com/map/im/12/49.2076/-122.8266. Note: The long straight lines are a bug in the Mapillary display. Because I have the raw images and GPX files, I haven't bothered to figure out a good workflow for using the Mapillary images in JOSM, and end up having a browser window open on one screen and JOSM on the other if I do need to use images from someone else. So, when mapping in Vancouver, consider Mapillary as a source. Technical: Images are captured at a settable interval, generally 2 seconds from a dash-mounted camera. Post-processing is then done for sharpness and contrast, time corrections applied, and the results correlated with GPX files from my GPS unit. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Winnipeg Open Data portal
On 8/1/2014 10:16 AM, Michael Zajac wrote: Does this look compatible with OSM? No one has yet evaluated the various OGL variants for compatibility with other licenses. I've gotten explicit statements of compatibility from some sources. For that matter, the various variants aren't listed as meeting the Open Definition[1]. If the data provider is unwilling to go with a standard license, they really need to explicitly indicate compatibility with other standard licenses. [1]: http://opendefinition.org/licenses/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Inaugural Vancouver Meetup - Tuesday October 28
On Tuesday October 28th, there will be an OpenStreetMap meetup held in Vancouver. http://www.meetup.com/OpenStreetMap-Vancouver/events/214167332/ We'll be holding it in the Bread Garden in Metrotown (http://www.openstreetmap.org/way/257886760), with convenient access to transit and nearby parking. Please RSVP on the Meetup page so we have an idea of numbers to let the restaurant know. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Municipal data source attribution
On 11/9/2014 8:48 AM, Steve Singer wrote: What is the current procedure for meeting the attribution requirement of a municipal data-source released under the 'Open Government Licence ? Unfortunately each Open Government License is different, and when I've asked about license compatibility I've received different answers from different licensors, so you'll have to ask the municipality about ODbL compatibility. I suggest asking about CC BY compatibility at the same time. I have gotten affirmative answers from the Federal government and BC. I have gotten a negative answer from the City of Vancouver. I've got queries out with some other BC cities, but nothing final from them. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] RIP CanVec
On 11/17/2014 5:50 PM, Stewart C. Russell wrote: Is there any way to de-tile the data? I realise that most of Canada is one giant water relation, but is there a data processing pipeline that can recognize and join up split entities? I looked at this, but it's better to go back to the original sources, particularly now that CanVec is no longer being updated. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-ja] osapon imports
From: Satoshi IIDA [mailto:nyamp...@gmail.com] Sent: Tuesday, October 16, 2012 3:59 PM To: OpenStreetMap Japanese talk Cc: d...@osmfoundation.org Subject: Re: [OSM-ja] osapon imports Hi Please let me confirm one point. Is it mandatory to using dedicated account to import? We devided the import works, and did from our personal account. Apologies for my lack of understanding. We know more about imports now than we used to, so imports in the past aren't really an issue. For something like this, yes, it needs to be from a dedicated account. ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 市の名称: ローマ字
Also sorry for answering with English. The practice in some regions of using name=Local Name (English Name) breaks multi-lingual renderings *badly*, because if you try to then do an English map you end up with English Name (Local Name (English Name)). The OSM.org Mapnik rendering is not intended to be an English map or a map using the most common international name, it is intended to be a map which displays the local name. From: Fabien SK [mailto:fabie...@gmail.com] Sent: Wednesday, September 04, 2013 2:04 PM To: OpenStreetMap Japanese talk Subject: Re: [OSM-ja] 市の名称: ローマ字 Sorry for answering in English. In fact I think that filling the name:* for each language would be the best for the data. But currently Mapnik only uses name, and even if it contains the roman name, it will not be practical for russian, arabian and indian people for example. Fabien Le 04/09/2013 11:38, ikiya a ecrit : ikiyaです。 古橋さん name は日本語のみ name:en, name:ja_rm, name:ja_kana 等を併用して多言語化していく方向に賛成で す。 いいださん 僕はカッコ書きをやめたいと思っています。 (name:enや name:ja_rm, name:ja_kana を使うようにしたい) 私もname:en, name:ja_rm, name:ja_kana 等を併用して多言語化していく方向に賛成 です。 nameを日本語のみにすることも将来的には賛成です。 ただ慎重論ですが、現状のローマ字併記を消す、止めるタイミングは考えたほうが良 いと思います。 現状でmapnikのレンダリングで日本の地図のローマ字表示、読みを必要として利用し てたり、 今までのルールでローマ字読みのマッピングに注力、mapnikで確認されたい方々がい るとしたら 困ると思います。 今後は多言語対応のレンダリングサイトもよりメジャーになってくると思います。 多言語対応のOSMレンダリングサイトがosm.orgのmapnikなみに利用できる環境になっ てから 現状のローマ字併記を消す、止めるのがよいかと思います。 よい多言語対応サイトがあればローマ字表示が必要 なユーザーに薦めることも 方法かとは思います。 *** Fabien SKさんへ、質問します。 日本語とローマ字の名称が両方あったほうがよいですか？ もし、そうであれば、 日本語とローマ字があるほうがよい理由をお知らせください。 --- On Wed, 2013/9/4, Taichi Furuhashi mailto:tai...@osmf.jp tai...@osmf.jp wrote: 古橋です。 name は日本語のみ name:en, name:ja_rm, name:ja_kana 等を併用して多言語化していく方向に賛成で す。 2013年9月4日 13:35 Satoshi IIDA nyamp...@gmail.com: いいだです。 ほかのいくつかの国は最近このパターンをやめました。（例えば、 タイ。） 代わりに、name:en とか name:ja_rm とか使うようになっていました。 ローソンさんデータのインポートに関するメールでも書いたのですが、 僕はカッコ書きをやめたいと思っています。 (name:enや name:ja_rm, name:ja_kana を使うようにしたい) 他のみなさんはいかがでしょうか？ 2013年9月4日 8:25 Douglas Perkins doug...@dperkins.org: ダグラスです。 On 09/04/2013 04:08 AM, Fabien SK wrote: Fabienです。 あの変更でローマ字の名称は除かれていた。 http://www.openstreetmap.org/browse/changeset/15407085 あのページによれば日本語とローマ字の名称の必要です。 http://wiki.openstreetmap.org/wiki/JA:Multilingual_names#.E6.97.A5.E6.9C.AC 今にはそのページは 「name=日本語 (ローマ字)」が書いています。 ほかのいくつかの国は最近このパターンをやめました。（例えば、タイ。） 代わりに、name:en とか name:ja_rm とか使うようになっていました。 OSM日本はこれからなにか予定がありますか？ 私は意見ないですが、もし予定があれば、知りたいと思います。 この編集を取り消してもよろしいですか。 ごめんなさい、わたしは日本語がうまく話せません。 Fabien ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap Foundation Japan with sinsai.info http://sinsai.info/ project ## Director of the OSGeo Foundation Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## TEL/SkypeTwitterLIFB: 070-6401-5963 / http://about.me/mapconcierge ## URL/Mail: http://www.mapconcierge.jp http://www.mapconcierge.jp/ tai...@mapconcierge.jp ## GPS/GigaPan/UAV Shop: http://gpsconcierge.jp http://gpsconcierge.jp/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] Deletable KSJ2 import tags
I was working on osm2pgsql stuff and ran across a lot of tags from the KSJ2 import, many of which can probably be deleted. It looks the shapefile - osm conversion dumped all the shapefile attributes in as KSJ:* tags Below are a couple of samples, English in brackets is a translation Way 235010334 KSJ2:COP_label = 不明 [Unknown] KSJ2:DFD = 流下方向判明 [Flow direction found] KSJ2:LOC = c-1734 KSJ2:RIC = 860604 KSJ2:RIN = 名称不明 [Unknown name] KSJ2:WSC = 860604 KSJ2:curve_id = c-1734 KSJ2:filename = W05-09_26.xml KSJ2:river_id = r-1734 Way 23794809 KSJ2:AAC = 07367 KSJ2:AAC_label = 福島県南会津郡只見町 [Fukushima Prefecture Minamiaizu-gun Tadami town] KSJ2:ARE = s19401 KSJ2:HOW = 510 KSJ2:LDM = 0 KSJ2:LPN = 田子倉湖 [Tagokurako] (The value of the name=* tag) KSJ2:curve_id = c19403 KSJ2:curve_type = interior KSJ2:lake_id = gc01_194 Could someone more familiar with the import comment on what tags should be added to the list of tags that editors remove? ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [Imports] Deletable KSJ2 import tags
From: Satoshi IIDA [mailto:nyamp...@gmail.com] Sent: Saturday, September 07, 2013 3:33 AM Subject: Re: [Imports] Deletable KSJ2 import tags I think all the those tags are deletable. Unless someone objects I'll be going with the following tags as some of the ones I listed earlier occur very seldom: KSJ2:ARE KSJ2:COP_label KSJ2:DFD KSJ2:LOC KSJ2:LPN KSJ2:RIC KSJ2:RIN KSJ2:WSC KSJ2:coordinate KSJ2:curve_id KSJ2:curve_type KSJ2:filename KSJ2:lake_id KSJ2:lat KSJ2:long It was added because of the issue of interpretation of licensing words, and it is now cleared. (We JP confirmed it, tagging source, source_ref, and note:ja are enough, as written in KSJ2 page) http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import http://lists.openstreetmap.org/pipermail/talk-ja/2012-November/006930.html Just to clarify, there are no *legal* reasons that source, source_ref and note:ja cannot be removed by anyone at any time. Of course doing that in bulk to the osm.org database wouldn't be done, but is legally possible and downstream consumers do it all the time to their derivative databases. ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [Imports] Deletable KSJ2 import tags
Any issues with changing this to the following? All tags have 100k uses and seem to be duplicating other information already present, or not of any interest to OSM. KSJ2:ADS KSJ2:ARE KSJ2:AdminArea KSJ2:COP_label KSJ2:DFD KSJ2:INT KSJ2:INT_label KSJ2:LOC KSJ2:LPN KSJ2:OPC KSJ2:PubFacAdmin KSJ2:RAC KSJ2:RAC_label KSJ2:RIC KSJ2:RIN KSJ2:WSC KSJ2:coordinate KSJ2:curve_id KSJ2:curve_type KSJ2:filename KSJ2:lake_id KSJ2:lat KSJ2:long KSJ2:river_id -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Saturday, September 07, 2013 8:27 PM To: 'Satoshi IIDA' Cc: impo...@openstreetmap.org; 'OpenStreetMap Japanese talk' Subject: Re: [Imports] Deletable KSJ2 import tags From: Satoshi IIDA [mailto:nyamp...@gmail.com] Sent: Saturday, September 07, 2013 3:33 AM Subject: Re: [Imports] Deletable KSJ2 import tags I think all the those tags are deletable. Unless someone objects I'll be going with the following tags as some of the ones I listed earlier occur very seldom: KSJ2:ARE KSJ2:COP_label KSJ2:DFD KSJ2:LOC KSJ2:LPN KSJ2:RIC KSJ2:RIN KSJ2:WSC KSJ2:coordinate KSJ2:curve_id KSJ2:curve_type KSJ2:filename KSJ2:lake_id KSJ2:lat KSJ2:long It was added because of the issue of interpretation of licensing words, and it is now cleared. (We JP confirmed it, tagging source, source_ref, and note:ja are enough, as written in KSJ2 page) http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import http://lists.openstreetmap.org/pipermail/talk-ja/2012-November/006930. html Just to clarify, there are no *legal* reasons that source, source_ref and note:ja cannot be removed by anyone at any time. Of course doing that in bulk to the osm.org database wouldn't be done, but is legally possible and downstream consumers do it all the time to their derivative databases. ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] CJK fallback fonts - testing needed
Right now the main OpenStreetMap.org stylesheet uses Unifont as a fallback font to render Chinese, Japanese and Korean (CJK) characters, as well as any other characters not present in the DejaVu font. Unifont is mainly designed to support all characters, and is not designed to look good. I'm looking at Droid Sans Fallback, a free font developed for Android, and evaluating if it would be a better fallback font than Unifont. Because I don't read Chinese, Japanese or Korean, I could use help. I have prepared a demo at http://tile.paulnorman.ca/demo/fonts.html with three layers: conventional OSM.org, tiles without any fallback font, and tiles using Droid Fallback as a fallback font. What I would like is for people to look at the difference between the conventional OSM.org and Droid Fallback tiles and see which is easier to read for the CJK glyphs. The tiles without any fallback font can be used to find areas where DejaVu doesn't have glyphs and the fallback font is being used. Some examples Japanese cities: http://tile.paulnorman.ca/demo/fonts.html#9/35.443/138.247 Japanese train stations: http://tile.paulnorman.ca/demo/fonts.html#16/36.415/139.325 Korean cities: http://tile.paulnorman.ca/demo/fonts.html#9/37.25/127.22 Chinese tourist attraction: http://tile.paulnorman.ca/demo/fonts.html#15/39.94/116.48 Please keep in mind that - My server is not nearly as powerful as tile.osm.org, so renders slower and has less cached data - Only Asia is loaded on my server - The data is a couple of days old and isn't being updated I would like some feedback on if Unifont or Droid Sans Fallback looks better. Please keep in mind that I don't read the languages being rendered. ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [OSM-talk] CJK fallback fonts - testing needed
From: Paul Norman [mailto:penor...@mac.com] Sent: Saturday, January 11, 2014 9:19 PM To: t...@openstreetmap.org; talk-ja@openstreetmap.org; talk- k...@openstreetmap.org Subject: [OSM-talk] CJK fallback fonts - testing needed Right now the main OpenStreetMap.org stylesheet uses Unifont as a fallback font to render Chinese, Japanese and Korean (CJK) characters, as well as any other characters not present in the DejaVu font. Unifont is mainly designed to support all characters, and is not designed to look good. I'm looking at Droid Sans Fallback, a free font developed for Android, and evaluating if it would be a better fallback font than Unifont. Because I don't read Chinese, Japanese or Korean, I could use help. I have prepared a demo at http://tile.paulnorman.ca/demo/fonts.html with three layers: conventional OSM.org, tiles without any fallback font, and tiles using Droid Fallback as a fallback font. What I would like is for people to look at the difference between the conventional OSM.org and Droid Fallback tiles and see which is easier to read for the CJK glyphs. The tiles without any fallback font can be used to find areas where DejaVu doesn't have glyphs and the fallback font is being used. I've gathered various feedback and comments The fonts are too small Andy wants to increase the font size, but this is a separate issue. Currently the smallest font-size is 8pt, so even if everything gets bumped up 2pt, that's still 10pt. Rendering POIs on a webmap means you need small fonts to get everything in. The hinting and anti-aliasing of the characters is bad It's not clear if this comment is about it being bad, or it being worth with Droid Fallback than with Unifont. The first is not relevant for what I'm looking at right now, but the second would be a concern. Missing glyphs It is intentional that I am missing glyphs on the test rendering, as I don't want Unifont used at all while testing. Different fonts are needed for labels based on their language, even when the characters are the same in two labels This is a complicated one. Frankly, as long as people are using tags like name=近畿 (Kinki Region) instead of putting the name of the feature as it is on the ground (e.g. name=近畿), the chances of being able to do this are about zero. If it was tagged consistently, you could maybe detect that name is the same as name:xx, know that you're in the xx language, and adjust fonts accordingly. This would be some time off, and definitely out of scope for what I'm doing right now. smaller pieces of kanji are easier to read with droid sans droid font looks better for Hangul Good feedback to hear ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] iD en_GB localization
Unlike the OSM website, the default language for the iD editor is en_US. Because there are differences between en_US and en_GB, I've had an en_GB translation added, but translators are needed to fill it out. Instructions for translating iD are at https://github.com/systemed/iD/blob/master/CONTRIBUTING.md#translating and the en_GB translation can be found at https://www.transifex.com/projects/p/id-editor/language/en_GB/. With my background I can easily shift between en_CA, en_GB and en_US so I don't always notice when something is written in one dialect or the other, so help is needed filling out the translations. So far I've done a few obvious translations and undone conversions of the base text to en_US. Obviously because en_US and en_GB are relatively similar not everything will need translating, but it'd be nice to get what needs translating done. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
From: SomeoneElse [mailto:li...@mail.atownsend.org.uk] Subject: Re: [Talk-GB] Editor backbground layers in iD Rob Nickerson wrote: 2). iD is a general purpose editor. It can be used for OpenHistoricalMap too. Indeed - perhaps I should have been clearer that I'm talking about the instance in use on the OSM site used to edit the OSM map, not any other instance which presumably could feature any layers that it liked. It's worth pointing out that iD doesn't actually have an imagery list. It inherits its from the editor-imagery-index project at http://osmlab.github.io/editor-imagery-index/, which is for OpenStreetMap editing, not historical mapping or a general list of all possible imagery. So how do we deal with an overload of map layers? I think it's a tool issue. Indeed - and I'm sure that the iD developers would say patches welcome at this point! Dealing with it from a UI perspective is difficult, and I get the impression that's the main issue, not the coding once the UI is figured out. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
From: SomeoneElse [mailto:li...@mail.atownsend.org.uk] Sent: Friday, November 01, 2013 4:44 AM To: Paul Norman; talk-gb@openstreetmap.org Subject: Re: [Talk-GB] Editor backbground layers in iD Paul Norman wrote: It's worth pointing out that iD doesn't actually have an imagery list. It inherits its from the editor-imagery-index project at http://osmlab.github.io/editor-imagery-index/, which is for OpenStreetMap editing, not historical mapping or a general list of all possible imagery. Thanks Paul - that's something that I hadn't realised. From the comments above, presumably the open historical map people are using the same list rather than one tailored to historical mapping though? They shouldn't be. The editor-imagery-index project is targeted at the needs of OpenStreetMap, not of other projects. With how the index is setup with each layer being its own file it is trivial to automatically copy in additional files before running make. In fact, there are layers in editor-imagery-index which can't be used outside of OSM. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
From: Paul Norman [mailto:penor...@mac.com] Sent: Wednesday, October 30, 2013 3:03 PM To: 'SomeoneElse'; talk-gb@openstreetmap.org Subject: Re: [Talk-GB] Editor backbground layers in iD It's worth pointing out that iD doesn't actually have an imagery list. It inherits its from the editor-imagery-index project at http://osmlab.github.io/editor-imagery-index/, which is for OpenStreetMap editing, not historical mapping or a general list of all possible imagery. There is now https://github.com/osmlab/historic-imagery-index, an imagery index that takes its own list of historic layers and combines it with the layers in editor-imagery-index. To use it in JOSM all you need to do is modify imagery.layers.sites in advanced preferences to add http://osmlab.github.io/historic-imagery-index/imagery.xml I've added some layers that appear have value purely for historical mapping to it and opened the pull request https://github.com/osmlab/editor-imagery-index/pull/35 to remove them from editor-imagery-index. Are there any *non*-historical uses for NLS - Bartholomew Half Inch, 1897-1907; NLS - OS 1-inch 7th Series 1955-61; or OS New Popular Edition historic. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] [OSM-talk] Hobbyist OSM Data Server?
From: Nick Whitelegg [mailto:nick.whitel...@solent.ac.uk] Sent: Friday, December 06, 2013 4:59 AM Subject: [OSM-talk] Hobbyist OSM Data Server? So I'm wondering whether we could, if enough people raise contributions, have an OSM read only, hobbyist server which could be used to host not-for-profit, open source (only) projects. it could be either global or just for the UK (or any other individual country). It could contain a copy of the OSM PostGIS database then developers could be free to host server side code which delivers that data in whatever format fits their own needs (GeoJSON, some binary vector format, or anything else). You should keep in mind the dev server (errol), both for running whatever you want to and when planning additional resources if you need them. You can find information on the dev server at http://wiki.openstreetmap.org/wiki/Using_the_dev_server. The dev server has an osm2pgsql database, kept up to date every hour and imported with hstore and extra attributes (metadata). This is a fairly flexible schema, but it's not too widely know that it's running as a shared resource. It is suitable for rendering and many types of analysis queries, and more flexible than pgsnapshot, apidb or another schema closer to the original OSM data. The database is on the RAID5 array of 7200RPM drives, so it's not exactly fast IO, but it keeps up and isn't maxed out. The server is of course a shared resource, and suffers from the same problem of any shared resource: others badly written code may end up impeding your access. Of course what you're proposing can suffer from that same problem too. The EWG has periodically discussed how the dev server could be more useful, and I know reasonable feedback and ideas are welcome, either at the meetings on Monday (http://www.osmfoundation.org/wiki/Engineering_Working_Group#Meetings) or on the dev@ mailing list. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Adding links to Wikidata (and Wikipedia?)
On 2014-06-08 1:28 PM, Rob Nickerson wrote: What would you consider a demonstration of success exactly? Tom Tom, Measuring the success of a bot can be done in the same way that the success is measured in a statistical model; Type I and Type II errors. So for example, if the test is to attach wikidata tags to churches then: Measured that way, I could code a bot that sets name=foo for all objects with a name tag. Assuming I'm decent at coding, I could have zero Type I and Type II errors, and by those criteria this mechanical edit would be a success. Success should be measured against the reasons for the mechanical edit. Adding wikidata tags isn't the reason, it's what it does. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
