Re: [Talk-ca] Municipal boundaries
Municipalities are creatures of the provinces, the most likely source of complete, correct municipal boundaries will be the provincial government, though each municipality will generally know theirs (and sometimes disagree with neighbours, hence the utility of using a provincial file if available). Matching of CSDs with municipal boundaries is something StatsCan will attempt to achieve, but it's by no means a guarantee. If the goal is "good enough", CSDs are good enough. If the goal is to reflect reality, provincial data will always be preferable. e.g. https://catalogue.data.gov.bc.ca/dataset/municipalities-legally-defined-administrative-areas-of-bc P On Tue, Mar 7, 2017 at 6:31 AM, James wrote: > In purple/black CSD 2016, in gold Gatineau's city limits from their open > data portal: > http://i.imgur.com/undefined.png > > The CSDs do not match up with actual city bounds > > On Tue, Mar 7, 2017 at 9:20 AM, Bjenk Ellefsen > wrote: > >> Just to make sure we are talking about the same thing: Census Divisions >> are higher level and more regional boundaries. CSDs are municipal >> boundaries (in OSM, level 8). http://www.statcan.gc.ca/eng/s >> ubjects/standard/sgc/2011/sgc-intro >> >> Can you give me an example of city limits that don't match a CSD or is >> not in the SGC? Usually, the standard for municipal boundaries are the >> CSDs. At least, as far as I know, this is the standard geography. When >> referring to actual city limits, which geographical classification is it >> referring to? >> >> Sorry for the questions, I am trying to understand what is the >> classification used if its not the CSDs. >> >> On Tue, Mar 7, 2017 at 9:11 AM, James wrote: >> >>> Bernie, I've also noticed that StatsCan boundaries seem to be a >>> generalization of an area vs the actual city limits >>> >>> On Tue, Mar 7, 2017 at 9:02 AM, Bernie Connors >> > wrote: >>> Bjenk, In NB there are issues with some census boundaries not matching with our administrative boundaries. The issue I am aware of was with the county boundaries. The census data that is analogous to our county boundaries included some significant deviations to prevent a municipality from being bisected by a county boundary. Please be careful that there is not a similar issue with the CSD boundaries. NB municipal boundaries can be downloaded from the GeoNB Data Catalogue For comparison to the CSD data. Bernie. Sent from my BlackBerry 10 smartphone on the Bell network. *From: *Bjenk Ellefsen *Sent: *Tuesday, March 7, 2017 9:51 AM *To: *talk-ca@openstreetmap.org *Subject: *[Talk-ca] Municipal boundaries Hello, Municipal boundaries correspond to census subdivisions (CSD). I have seen that many municipalities do not have a boundary yet. Is it ok if I start adding some boundaries based on CSDs? Having the boundaries is important to make extractions and analysis at the municipal level. Bjenk ___ 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] Canvec forest redux
On Thu, Sep 29, 2016 at 5:58 PM, Adam Martin wrote: > > You know, it suddenly strikes me that part of the reason that there is so > much trouble with the forest polygons from the Canvec data is less the > accuracy of the data and more the fact that it is brutally difficult to > work with. > This is my complaint about the forests. It's not just the fact they are loaded as complex features, it's that even the simple polygons are just packed full of vertices. So modifying them requires 5x the work of modifying other things. They're only partially loaded into OSM and unlikely to be updated. If there was ever a feature that a human-mediated map like OSM should skip, it's this kind of landcover stuff: if one needs a landcover in ones map, get a computer to do a classification of landsat 8, and load that into your map, it'll be better in a global sense than the handballed thing, and far more up to date than hand-massaged forest polygons that were captured in the mid-80s. P. > These enormous multipolygon relations, linking the forests to open areas, > wet lands, and water polygons, creating inner and outer relationships all > within the confines of the Natural Resources map divisions. I wonder would > these be nearly as hard to work with if the multpolygon relation itself > didn't exist? I understand the reasoning for relations themselves - they > are core mapping elements meant to describe logical arrangements between > items. Bus routes are one of the prime examples of such a thing. Has anyone > leaned back and just considered that, in the case of this forest data, we > might be going a bit far to have inner and outer boundaries to describe > breaks in the tree line? Think of it this way, what is the use of a > multipolygon relation? In the Wiki, it is used to create an area for which > the boundary is defined by multiple ways and / or an area possessing holes. > When we import a forest multipolygon, what are we trying to describe > exactly? An area of forest with holes ... which are not holes, but are > simply areas when the tree line breaks and another feature is present (open > grassy area, a lake, a marsh, etc. Looking over some of these polygons, it > is notable that houses or owned are often not provided a gap if they are > not in a city centre. Even more unnerving is the fact that roads, major or > minor, are also not provided gaps nor are they part of the relation. > Essentially, the most important human feature of an area - the > transportation network, is not important enough to be part of the relation. > > Perhaps it would be better to eliminate the multipolygon itself? Simply > map the forest areas and open areas and lakes and so forth and add them to > logical relations afterwards. Take my home province of Newfoundland. If one > were to build a forest polygon, it could be logically broken down into > regional multipolygons (such as one for the Avalon Penninsula). Or it could > even be further divided based on localized geometry. > > Just some thoughts on the matter. > > Adam > > On Thu, Sep 29, 2016 at 6:26 PM, Sam Dyck wrote: > >> Hi everyone >> >> Sorry for bringing this up, but I need to some Canvec importing. Given >> the controversy about Canvec earlier this month, I'm trying to decide how >> to do this. I could: >> >> - Leave the forests out entirely. >> - Or use it as an opportunity to experiment with the Manitoba Lands >> Initiative forest data. We've discussed MLI before and done some limited >> importing. And I'm curious to take a look at the data. >> >> Thoughts? >> >> Sam >> >> ___ >> 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] Forests/Land Use, was: Canvec reverts
On Thu, Sep 1, 2016 at 11:27 AM, Adam Martin wrote: > That is the key here. Deleting information without replacing it with > something more accurate is inherently destructive. There must be some > thought as to what will be put back or one is essentially ripping the map > up simply because you don't like how something looks or how it closely it > follows a given rule. > I'm not sure I agree. "Better than nothing" I guess is the principle, but when what is there (not nothing) gets in the way of improving other features, then it's not better than nothing. And what if what's there is, from an information point of view, basically nothing? Like the forests polygons that basically do nothing to delineate where forests actually are (or residential polygons with same issue?) "Go map all forests" is not actionable. Hell, even "clean up all forests in just the area you care about" isn't. There's too much. So instead, I leave demonstrably wrong "forests" in place. [image: Inline image 1] I can't even salve my conscience that they at least improve the rendering a little at an aesthetic (if not informational) level, since they were partially loaded in the region, and actually make it look worse. [image: Inline image 2] Anyways, I stick to my general feeling (un-acted upon) that more is not better, and the map would be easier to work with without the big, unhelpful, land cover polygons. P. > That would be like finding parking aisles tagged as drive throughs and > deleting them as incorrect, instead of simply correcting the tags. > > On Sep 1, 2016 3:30 PM, "john whelan" wrote: > >> And as someone who has deleted quite a few things in OSM I would agree >> with that statement. When I didn't have a better replacement available >> then I prefer not to delete unless I have done a ground level inspection >> and there really isn't anything there. >> >> I think my favourite was a mapper who was demonstrating 3D software with >> OSM. They dropped in a group of multiple level buildings into an area I >> was mapping in Africa. They didn't consider what they did was wrong, it >> was only Africa. >> >> Cheerio John >> >> On 1 Sep 2016 1:26 pm, "Begin Daniel" wrote: >> >>> *P: OSM is very much an "add only" project, since the social >>> consequences of incorrectly deleting things seem so high.* >>> >>> >>> >>> What I do perceive in the current thread is that deleting something not >>> perfect without replacing it with something better hurts, not that it is >>> not acceptable to delete something. >>> >>> >>> >>> Daniel >>> >>> >>> >>> *From:* Paul Ramsey [mailto:pram...@cleverelephant.ca] >>> *Sent:* Thursday, 1 September, 2016 13:05 >>> *To:* Begin Daniel >>> *Cc:* Talk-CA OpenStreetMap >>> *Subject:* Re: [Talk-ca] Forests/Land Use, was: Canvec reverts >>> >>> >>> >>> >>> >>> On Thu, Sep 1, 2016 at 8:49 AM, Begin Daniel wrote: >>> >>> What is very cool with OSM is that you can edit the data. Urban polygon >>> is wrong? Modify it! The definition is obscure in the Wiki? Change it! But >>> yes, the learning curve is often steep, and you may need to discuss with >>> someone else… >>> >>> >>> >>> "Just fix it" is not quite the answer. The point the original poster >>> made, which I concur with, is that the very existence of these shapes makes >>> working with the "important" data difficult. In terms of forest and land >>> use polygons, every vertex I move there is a vertex I'm not going to move >>> on something "important". (And the vertex density of the forests/land use >>> are another reason that working around/with them is painful and >>> energy-sapping.) >>> >>> >>> >>> As discussed in the other thread, the shear volume of Canada means I'm >>> never in 1M years going to "fix" the forests. As it stands, I mostly ignore >>> them. Too many vertexes to move, for too little net benefit, so there's >>> forests running through the new subdivisions of Prince George. At least the >>> roads are there and hopefully correctly named now. >>> >>> >>> >>> (I would, however, love to just delete the urban "land use" polygons, >>> but who know if that's "allowed" or not. Absent a strong personality like >>> the person who caused this t
Re: [Talk-ca] Forests/Land Use, was: Canvec reverts
On Thu, Sep 1, 2016 at 8:49 AM, Begin Daniel wrote: > What is very cool with OSM is that you can edit the data. Urban polygon is > wrong? Modify it! The definition is obscure in the Wiki? Change it! But > yes, the learning curve is often steep, and you may need to discuss with > someone else… > "Just fix it" is not quite the answer. The point the original poster made, which I concur with, is that the very existence of these shapes makes working with the "important" data difficult. In terms of forest and land use polygons, every vertex I move there is a vertex I'm not going to move on something "important". (And the vertex density of the forests/land use are another reason that working around/with them is painful and energy-sapping.) As discussed in the other thread, the shear volume of Canada means I'm never in 1M years going to "fix" the forests. As it stands, I mostly ignore them. Too many vertexes to move, for too little net benefit, so there's forests running through the new subdivisions of Prince George. At least the roads are there and hopefully correctly named now. (I would, however, love to just delete the urban "land use" polygons, but who know if that's "allowed" or not. Absent a strong personality like the person who caused this thread, it seems like OSM is very much an "add only" project, since the social consequences of incorrectly deleting things seem so high. Nobody wants to be "that guy".) ATB, P > > *From:* Paul Ramsey [mailto:pram...@cleverelephant.ca] > *Sent:* Thursday, 1 September, 2016 11:17 > *To:* Talk-CA OpenStreetMap > *Subject:* [Talk-ca] Forests/Land Use, was: Canvec reverts > > > > I'm "glad" to see someone else w/ this issue. It's glancingly related to > the canvec import issue, since the land use polygons are a source of some > of the issues the reverter is complaining about (malformed multipolygons / > boundary overlaps). > > > > In my own work in my old home town of Prince George, I've constantly > wanted to just plain delete the "urban area" land use polygon (which > doesn't seem to correspond in any way to the actual urban area of the > present) and the forest polygons (which have the same problem). > > > > Unlike buildings and roads and water, land use is pretty sloppy: where > does the "urban area" end? Is this a "forest" or just a bunch of trees? > Since anyone making a real multi-scale map will fine some other source of > land-use (like classified landsat) and since people trying to map at > high-res are finding the forests add little value and much impedance, why > don't we ... burn down all the forests (and the urban areas too)? > > > > P > > > > On Thu, Sep 1, 2016 at 6:54 AM, Loïc Haméon wrote: > > > On a final note, though, I certainly would approve of any effort to reduce > the size of the upload chunks and the assorted polygons. For new mappers > like me, those create daunting challenges when trying to make incremental > improvements to an area. Shortly after joining the OSM community I was back > in my home town of Saint-Félicien, in a fairly remote region that hasn't > had tons of local mapping done. Some of the inhabited areas I aimed to > improve were covered by Canvec forest multipolygons, and I ended up giving > up on them until I could get some more experience as I absolutely did not > understand what the hell was going on > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Forests/Land Use, was: Canvec reverts
I'm "glad" to see someone else w/ this issue. It's glancingly related to the canvec import issue, since the land use polygons are a source of some of the issues the reverter is complaining about (malformed multipolygons / boundary overlaps). In my own work in my old home town of Prince George, I've constantly wanted to just plain delete the "urban area" land use polygon (which doesn't seem to correspond in any way to the actual urban area of the present) and the forest polygons (which have the same problem). Unlike buildings and roads and water, land use is pretty sloppy: where does the "urban area" end? Is this a "forest" or just a bunch of trees? Since anyone making a real multi-scale map will fine some other source of land-use (like classified landsat) and since people trying to map at high-res are finding the forests add little value and much impedance, why don't we ... burn down all the forests (and the urban areas too)? P On Thu, Sep 1, 2016 at 6:54 AM, Loïc Haméon wrote: > > On a final note, though, I certainly would approve of any effort to reduce > the size of the upload chunks and the assorted polygons. For new mappers > like me, those create daunting challenges when trying to make incremental > improvements to an area. Shortly after joining the OSM community I was back > in my home town of Saint-Félicien, in a fairly remote region that hasn't > had tons of local mapping done. Some of the inhabited areas I aimed to > improve were covered by Canvec forest multipolygons, and I ended up giving > up on them until I could get some more experience as I absolutely did not > understand what the hell was going on > > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada
On Tue, Aug 2, 2016 at 11:46 AM, Ellefsen, Bjenk (STATCAN) < bjenk.ellef...@canada.ca> wrote: > Here is what we would invite Canadians to tell us about buildings for OSM: > > name > Address: > >- Number >- street >- city >- postal code > > A given footprint could easily encompass multiple street numbers (duplexes, for example). Something to consider. P. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New project update
Hey Bjenk, When you say "define a project" are you talking about (a) describing a scope of work that StatsCan intends to resource and complete? (b) describing a scope of work that StatsCan hopes the OSM community will complete on your behalf? You've used the passive voice in describing the actual collection in your description below, so it's not completely clear who you think will be collecting the information. ATB, P On Thu, Apr 21, 2016 at 8:35 AM, Ellefsen, Bjenk (STATCAN) wrote: > Hello everyone, > > Basically, what we would like to do is define a project for OSM to collect > information about non-residential buildings. > We would like to popose a list of what would be collected. We were thinking > of identifying specific areas to start with. > > Cheers, > > Bjenk Ellefsen, PhD > > Center for Special Business Projects | Centre des Projets Spéciaux sur les > entreprises > Statistics Canada | Statistiques Canada > > > > > ___ > 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] Talk-ca Digest, Vol 96, Issue 1
Yeah, from the outside looking in I'm not seeing the huge surprise. I'm not a community member, but I saw the initial emails from Mojgan, and he's also talked to folks face-to-face. I didn't see an email about the wiki page, but that could be because I wasn't paying attention. What would a good process look like? x- email: "hi, I'm a government organization and I'd like to engage this way, we want to do this" x- comment/response/refine x- wiki: "here is exactly what we plan to do and how we are going to do it" - email: "hi, we now have specific plans and have documented them here in the wiki for your comment" - comment/response/refine - email: "hi, we are going to run a small test import in the following area for your review, please comment" - import: "here's a small amount of data, exactly as we'd do it in a larger area" - email: "hi, we have run a small test import in the following area, please review and comment" - comment/response/refine - email: "hi, we are about to run our main import in the following area, please light your hair on fair if you still have a problem with this" - import: "boom, there it is" I did see the first three communications for sure, and maybe missed one on the wiki. Probably for a big import running a test import first would be a generally wise approach for getting feedback (similar to publishing a github branch). Triplinx has definitely been approaching this in very good faith, shame to see them get reverted for failing to follow a process that doesn't seem to be documented. They certainly met the "communicated" threshold, just maybe not enough or in the right ways for some folks? P. On Tue, Feb 2, 2016 at 6:51 AM, Begin Daniel wrote: > Initial misunderstandings, emails round trips with the community… standard > communication process! > > > > I do not know how others a seeing it, but reading about the process you use, > I do not see anything like a wild bulk import. At least, it is very similar > to the process I used when importing Canvec datasets. > > > > Daniel > > > > From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com] > Sent: February-02-16 09:33 > To: talk-ca@openstreetmap.org > Subject: Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1 > > > > Hi all, > > Please accept my apology for this misunderstanding, I thought our presence > for last OSM meeting and flowing emails in Talk-ca and with John were part > of communication and discussion, we launched our wikipage two weeks ago, and > we did not receive any feedback, so we thought to start import via JOSM. > > > > as we expalined in our wikipage, we created the algorithm to detect the > missing information, and then we check the quality of this information on > JOSM on the top of OpenStreetMap, Bing Areal imagery, GeoBase Road network > and some local municpal open data. the data is created initially through > StatCan, however, we noticed the low quality of StatCan road segment > geometry, so we deal with this issue by using complement dataset such as > OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local > municpal open data. all created nodes and ways are carefully inspected > visually using above dataset for more that 6 weeks. > > > > Our final verification will be on the OSM server (on-line) to avoid or > detect any issues. Our aim is having high quality address information in OSM > for sake of community. we were very prudent from the first step to have a > high quality source of information. > > > > I hope that the community will accept our contribution and enjoy to use the > data. > > > > Best regards, > > > > Mojgan > > > > > Mojgan (Amaneh) Jadidi, Ph.D. > > Postdoctoral Research Fellow > > GeoICT Lab > > York University > > Toronto > > > > ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/ > > > > On 2 February 2016 at 07:00, wrote: > > 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. Triplinx import (Stewart Russell) >2. Re: Triplinx import (john whelan) >3. Re: Triplinx import (Stewart Russell) > > > -- > > Message: 1 > Date: Mon, 1 Feb 2016 18:36:01 -0500 > From: Stewart Russell > To: talk-ca > Subject: [Talk-ca] Triplinx import > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > It seems that this import has started with no discussion. Here's the wiki > page: > https://wiki.openstreetmap.org/wiki/Triplinx_Metrolinx_Import_Plan > > Stewart > -- next part -- > An HTML attachment
Re: [Talk-ca] Talk-ca Digest, Vol 95, Issue 2
IMO, address points are the optimum for geocoding, since they don’t give incorrect locations as linear interpolations do, and they can provide an existence test for inputs. I hope OSM is happy to take address points! (Actually the optimum is to have both, so you can give exact answers where they exist and guesses where they don’t…) > On Jan 12, 2016, at 6:25 PM, Stewart C. Russell wrote: > > On 2016-01-12 02:37 PM, Mojgan Jadidi wrote: >> >> Greater Toronto Area and Hamilton, mostly in new subdivision areas. Our >> Our conflation methods is based on an in-house algorithm of buffering left >> and right sides of the street segments to detect the missing parts … > > Hi Mojgan - this is what really impressed me with your planned process: > that you're prepared to develop an elegant QC system to match up road > ways to address ranges. > > Using municipal data imports alone wouldn't get this kind of QC, and > we'd end up with with millions of address points rather than more > compact ranges. > > cheers, > Stewart > > > ___ > 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
