Re: [OSM-talk] finding overlapping buildings

[Denis Carriere]

+1 Good question John,

I'll also look into that as well, I really don't think there's a solution
for that in JOSM (find me all overlapping buildings that overlap by +50%).

*~~*
*@DenisCarriere*

On Tue, Nov 21, 2017 at 5:53 PM, john whelan  wrote:

> >Might have to write a script to do that.  I will look into it. I don't
> think there is a way to do it with the standard query syntax or mapcss.
>
> Thanks John
>
> On 21 November 2017 at 20:31, Mike Thompson  wrote:
>
>> >  I'm not after ever building that overlaps by a small amount
>> Might have to write a script to do that.  I will look into it. I don't
>> think there is a way to do it with the standard query syntax or mapcss.
>>
>>
>>
>> On Tue, Nov 21, 2017 at 6:25 PM, john whelan 
>> wrote:
>>
>>> >
>>> in JOSM
>>> 
>>> Search Syntax = Mapcss selector (lower left of search dialog)
>>>
>>> enter the following for the search string:
>>> area:closed:areaStyle[building] ⧉ area:closed:areaStyle[building]
>>>
>>> (The character ⧉ is unicode 29c9)
>>>
>>> This works but gives the same results as select buildings then validate
>>> with crossing ways.  I'm not after ever building that overlaps by a small
>>> amount its the duplicates if I can get them.
>>> Thanks John
>>>
>>> On 21 November 2017 at 19:06, Mike Thompson  wrote:
>>>
 This doesn't take into account the 50% overlap, but:

 in JOSM
 
 Search Syntax = Mapcss selector (lower left of search dialog)

 enter the following for the search string:
 area:closed:areaStyle[building] ⧉ area:closed:areaStyle[building]

 (The character ⧉ is unicode 29c9)


 On Tue, Nov 21, 2017 at 4:16 PM, john whelan 
 wrote:

> Can someone describe a method I can locate these in JOSM.  I'm not
> after crossing buildings but just those that are mapped twice so two
> buildings with 50% or more overlap.
>
> Straight duplicates aren't a problem but ones that are drawn twice by
> two different mappers are.  Yes I know it shouldn't happen but it does.
>
> Thanks John
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>

>>>
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Severed Dick

[Denis Carriere]

Unfortunately does names seem legit for that type of mountain bike trails,
these are not the first mountain bike trails names I've seen with those
types of names.

Seems like source of these edits come from a reputable editor.

*User: *BC Trail Guides

http://osmlab.github.io/osm-deep-history/#/way/402020482
http://osmlab.github.io/osm-deep-history/#/way/402020492

This doesn't look like this is a form form of vandalism, that's just BC
Canada for you ;)

*~~*
*@DenisCarriere*
*GIS Software & Systems Specialist*

On Wed, Oct 25, 2017 at 11:03 AM, Frederik Ramm  wrote:

> Hi,
>
>noticed a few funny trail names in this region near Vancouver:
>
> https://www.openstreetmap.org/#map=16/49.3365/-122.9791
>
> Quote possible they really *are* called "Severed Dick", "Shorn Scrotum",
> and "Cunt Buster", in which case they're of course totally legit to have
> on the map, however I've come across some made-up names like that in the
> past too. Maybe someone can check.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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-us] Bicycle infrastructure

[Denis Carriere]

For anyone interested, our local Cycling + OSM community is currently
working on an OSM Bike Ottawa Tagging Guide.

https://github.com/osmottawa/OSM-Bike-Ottawa-Tagging-Guide

It mentions features like sharrows & bicycle shared lanes with in-depth
photos using Mapillary.

For any avid OSM cyclist, we would definitely welcome some feedback using
the GitHub issues.

Happy cycling!

Cheers,


*~~*
*@DenisCarriere*
*GIS Software & Systems Specialist*

On Wed, Oct 4, 2017 at 5:46 PM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> Martijn and this thread's contributors:
>
> Yes to everything!  Thanks for the OT snippet, that's helpful and benefits
> from additional suggestions like sharrows as cycleway=shared_lane,
> cycleway=buffered_lane, and importantly, shoulder and surface data.
>
> While infrastructure is important (critical, in fact), please also include
>
>   relation[route=bicycle](area.a);
>
> in that OT query, if you might.  (Or, perhaps as a separate query with the
> same area[name="Utah"]->.a; enveloping it).  Important things to check on
> in those results would be if the members of such relations contain
> exclusively bicycle infrastructure, and if not, tagging the member elements
> properly so they do.  And, check the relation tags so they are sensible and
> in correct networks (lcn, rcn, ncn).  Please read wiki docs if it isn't
> clear, but note that mountain bike routes (route=mtb, of which I'm sure
> Utah has many) are different than route=bicycle.  Please assure such routes
> are tagged accordingly.
>
> GO Utah bicycling, and find out how taking OSM with you (on your
> smartphone or GPS as a map or route, for example) is awesome!
>
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] SEO Damage to OSM

[Denis Carriere]

Great research Frederik!

*~~*
*Denis Carriere*

On Wed, Jul 5, 2017 at 5:05 PM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> > These spam changes do not need that complexity to detect.
>
> I've done some numbers, maybe it helps.
>
> I counted all users that only ever commited one changeset with one edit
> inside. This number is 140352.
>
> Then I discarded those where the changeset comment was shorter than 50
> characters or where the content had been redacted long time ago, leaving
> me with 12173.
>
> Then I looked at the objects modified/created, and discarded all where
> the object had neither website, nor description, nor note tag. This left
> me with 3323 objects.
>
> Then I looked at the list and found a broad range of edits. Some, while
> having an advertising slant, seem a legit addition of someone's own
> business:
>
> user=Martin Merkur
> changeset=38362589
> comment=Our doors are always open.  Come and visit, taste our coffee,
> see what we do
> object=node 4103514010
> addr:city=Berlin;addr:housenumber=38;addr:postcode=
> 12435;addr:street=Elsenstraße;amenity=cafe;cuisine=coffee_
> shop;internet_access=no;name=passenger
> coffee;note=https://www.facebook.com/PassengerEspresso/;opening_
> hours=7:30-15:00
> Uhr;smoking=outside;website=passenger-coffee.de
>
> or
>
> user=otheryan
> changeset=13150739
> comment=Added in West Town Bikes as it is at the same address and has
> enough of its own activity that it needs to be recognized on the map.
> object=node 1585399965
> addr:housenumber=2459;addr:postcode=60622;addr:street=W
> Division;name=Ciclo Urbano/West Town
> Bikes;shop=bicycle;website=http://ciclourbanochicago.com/
>
> some look more SEO-y
>
> user=northcarolinahealth
> changeset=43324244
> comment=Updated Osborne Insurance Services at Raleigh, NC
> object=node 4474950186
> addr:city=Raleigh;addr:housenumber=5316;addr:postcode=27609;addr:state=NC;
> addr:street=Six
> Forks Road;hours=Mon-Fri
> :8.00AM-6.00PM;name=Osborne Insurance
> Services;phone=919-845-9955;suite=110;website=http://
> northcarolinahealth.org
>
> or
>
> user=blakemanhart
> changeset=43027180
> comment=Updated State Farm - Blake Manhart at Springfield, VA
> object=node 4456153164
> addr:city=Springfield;addr:housenumber=8322;addr:
> postcode=22152;addr:state=VA;addr:street=Traford
> Ln #B;name=State Farm -
> Blake Manhart;Owner=Blake
> Manhart;phone=703-992-9664;website=http://blakemanhart.com
>
> I had a look at trying to automatically match website and user name; 457
> of them actually contain the user name in the web site. but that is a
> too coarse check. I fear that it might be necessary to look through the
> rest manually to detect the dodgy ones.
>
> Of the 3323, 208 have a highway tag. But here it bites me that I took
> everything that had either note or description or website, because some
> of the edits with highway=* are legit and have a description/note where
> the newbie mapper explained what they did. 170 of the 208 do have a
> website tag, and finally, they *all* seem dodgy. (Interestingly it was
> not all ways - some highway=traffic_signals too!)
>
> I've run a revert on these 170 but the majority had already been fixed
> by others!
>
> That leaves us with a good 3115 objects to investigate. Many do clearly
> violate our "no advertising" rules but then again we don't want to bee
> to harsh with the cycle shop owner who maybe oversteps the line.
>
> I've put my interim results here
>
> http://www.remote.org/frederik/tmp/username-in-url.csv
>
> (for those where the username is in the URL) - do you think we should
> revert them all automatically? (Keep in mind many may have been reverted
> already - we'd only work on those where the spam version is still current.)
>
> and
>
> http://www.remote.org/frederik/tmp/other.csv
>
> for those where the username is not (fully) in the URL.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] FBI using OSM on website... without attribution

[Denis Carriere]

It's not Leaflet's fault the attribution is incorrect, their website is
disabling the default attribution and adding a custom one.

*~~*
*Denis Carriere*

On Fri, Jun 30, 2017 at 3:37 PM, Dale Puch <dale.p...@gmail.com> wrote:

> A better route is to contact http://leafletjs.com/ since they are
> providing the actual map data thru their script.  Also they probably do so
> for lots of other sites.
> Leaflet does attribute Openstreetmap at the bottom of their main page page
> though.
>
> Dale Puch
>
> On Fri, Jun 30, 2017 at 2:36 PM, David Kewley <david.t.kew...@gmail.com>
> wrote:
>
>> It looks like all the FBI field office sites are essentially part of the
>> national site, so they're all probably managed centrally. They all credit
>> Leaflet in the map widget, and use OSM tiles without crediting OSM.
>>
>> It's been years since I've noticed webmaster links, like we used to have
>> in the early days of the Web. Poking around, I couldn't find any technical
>> feedback links at all on fbi.gov. Ideas for contacting someone who might
>> be able to help with this issue:
>>
>>- Call the national FBI number: (202) 324-3000 from
>>https://www.fbi.gov/contact-us/fbi-headquarters
>><https://www.fbi.gov/contact-us/fbi-headquarters>.
>>- Email one of the Community Outreach addresses available at various
>>field offices ("Community Outreach" link near the top of each field
>>office's page). E.g. for the San Francisco office, it's
>>outreach...@ic.fbi.gov from https://www.fbi.gov/conta
>>ct-us/field-offices/sanfrancisco/community-outreach-1
>>
>> <https://www.fbi.gov/contact-us/field-offices/sanfrancisco/community-outreach-1>.
>>Some other field offices also have outreach email addresses.
>>- On their "Businesses" page https://www.fbi.gov/resources/businesses,
>>they have a link for "Intellectual Property Theft/Piracy" at
>>https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft
>><https://www.fbi.gov/investigate/white-collar-crime/piracy-ip-theft>.
>>While this issue seems economically tiny compared to the IP theft issues
>>they tend to spend time on, it might be possible to get someone's help 
>> this
>>way, since it's their own website. (Although the reporting methods I found
>>went to other offices, not obviously directly to the FBI.)
>>
>> I won't be following up on these in the foreseeable future, but if
>> someone else does follow up, please let us all know what happens.
>>
>> David
>>
>> On Fri, Jun 30, 2017 at 10:40 AM, Joseph R. Justice <jayare...@gmail.com>
>> wrote:
>>
>>> On Thu, Jun 29, 2017 at 4:14 PM, Mike Thompson <miketh...@gmail.com>
>>> wrote:
>>>
>>> https://www.fbi.gov/contact-us/field-offices/denver
>>>>
>>>> See map in upper right part of page
>>>>
>>>
>>> Does either the page for the Denver field office, and/or the nation-wide
>>> field office locator referred to in a separate post in this thread, include
>>> a "Contact the Webmaster" sort of link?  Or even just a "Contact Us" link?
>>> Those would be a first obvious point of contact, I'd think...
>>>
>>>
>>>
>>> Joseph
>>>
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Denis Carriere]

There's many of us that are from the local Ottawa area, we will make sure
we capture those exceptions. I am sure in the Downtown area we will find
some valid trees that are completely within the building (green spaces on
top of a roof).

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jun 29, 2017 at 8:34 AM, Martin Koppenhoefer <dieterdre...@gmail.com
> wrote:

>
>
> sent from a phone
>
> > On 29. Jun 2017, at 14:01, Rory McCann <r...@technomancy.org> wrote:
> >
> > When doing an import, it's important that someone does this sort of
> > work. That's part of the process of doing an import, to learn more about
> > the accuracy of the data you have, and to check how it would look after
> > you import it. You shouldn't just presume everything will fit together
> > 100%, someone needs to do this sort of analysis.
>
>
> yes, it will give you some indication about obvious or very likely errors,
> still there are also trees inside buildings, it is a rare situation, but I
> could recall several instances where I've seen it (both, buildings built
> around trees/leaving gaps/holes, and trees being planted inside buildings).
>
> Problems like these are obvious, but there's no indication that the rest
> of the trees are more correct, it might be just harder to spot the issues
> when the data seems fine on first glance.
>
> Are you local to the area? I'd look for some trees you know that fell in
> the past years and see whether these events are reflected.
>
> Cheers,
> Martin
>
>
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Imports] Ottawa, Canada Tree Import

[Denis Carriere]

Thanks Rory,

Knowing that there's 622 trees in buildings is good information, the import
should definitely have a look at those specific trees and exclude them from
the import (tackling them manually is a good idea).

The building interpolation & building address issue should be discussed as
a separate thread.


*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jun 29, 2017 at 8:01 AM, Rory McCann <r...@technomancy.org> wrote:

> Hi.
>
> I think there's been a misunderstand, maybe I'm not being clear.
>
> I did some quick analysis of the data & current OSM data. There are
> about 622 trees which are inside a building. about 300 which are <1m
> from the centre line of a road.
>
> For example there are some trees-inside-buildings around here (
> https://www.openstreetmap.org/#map=17/45.39017/-75.75801 ) and (
> https://www.openstreetmap.org/#map=16/45.4187/-75.7007 ). My JOSM
> validator didn't flag "tree inside building", so you can't rely on that
> to figure it out.
>
> There are "trees very close to road centreline" around here (
> https://www.openstreetmap.org/#map=18/45.28647/-75.70499 ) or (
> https://www.openstreetmap.org/#map=18/45.40001/-75.75015 )
>
> For a dataset of 150k, these numbers are pretty good.
>
> When doing an import, it's important that someone does this sort of
> work. That's part of the process of doing an import, to learn more about
> the accuracy of the data you have, and to check how it would look after
> you import it. You shouldn't just presume everything will fit together
> 100%, someone needs to do this sort of analysis.
>
> I suggest you filter out the small number of suspicious trees, and
> either manually enter them, change the OSM data, and/or contact the City
> of Ottawa to tell them about possible errors in their data.
>
> BTW I noticed there are lots of address interpolation ways from a 2011
> CanVec import, and then lots of buildings with address tags from a
> building import this year. The old address lines weren't removed, so I
> think there are thousands (hundreds of thousands) of duplicate addresses
> in Ottawa? Have you noticed this? This is a danger of doing an import
> without looking at the existing OSM data.
>
> Doing some data analysis isn't a "mechanical edit", you're looking at
> the data, not editing it.
>
> Rory
>
> On 28/06/17 17:13, James wrote:
>
>> Other than MANUALLY VERIFYING EACH AND EVERY TREE, there is no way to
>> give a statistical analysis of the accuracy of the entire dataset. If we
>> did it programatically we'd have to prove how the method of analysis is
>> correct and would be probably be brushed off as being a "mechanical edit"
>> thus invalid. If the need to verify each tree is not on a
>> road/water/building this could be accomplished during the import(what I
>> like to call a manual import: where the data is validated at the time of
>> the importation of data as to the accuracy of the location and not just a
>> massive dump of data in one pass)
>>
>> On Wed, Jun 28, 2017 at 11:02 AM, Rory McCann <r...@technomancy.org
>> <mailto:r...@technomancy.org>> wrote:
>>
>> On 28/06/17 16:53, Kyle Nuttall wrote:
>>
>> I am still a little confused by what you mean. Obviously if
>> there's a
>>   tree in the middle of a building, that means something is not
>> right.
>> But what I was trying to say was that the trees in this dataset
>> will
>> only appear where an actual tree is in real life. There shouldn't
>> be
>> any cases of rogue trees in the middle of rivers or buildings
>> because
>> a tree just wouldn't be there in real life.
>>
>>
>> What if OSM data is wrong? What if OSM says "The river bank goes up to
>> here" and it doesn't, and that would make the tree in the river.
>> Sometimes people just upload data into OSM without checking for things
>> like this, and you get these weird data problems. You should try to
>> figure where (if at all) this happens, and see if the problem is OSM
>> or
>> the official data.
>>
>> You're also presuming the official data is 100% guaranteed to have the
>> correct location. If they are 99.9% accurate, then there are 150 wrong
>> locations. 99.99% accurate, 15 wrong locations.
>>
>> If you do this sort of analysis you can find out just how accurate the
>> official data is, and also prevent making the map be full of these
>> mistakes.

Re: [Talk-ca] Ottawa, Canada Tree Import

[Denis Carriere]

+1 That's awesome work!

So many tree related OSM tags!

http://www.openstreetmap.org/node/4937732175

If all the data looks like this, then it looks like it would be a great
import.

Best of luck!

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Tue, Jun 27, 2017 at 3:07 PM, Kyle Nuttall <kyle.nutt...@hotmail.ca>
wrote:

> A friendly hello to everyone,
>
>
> With the recent approval of the Ottawa ODL, I've had a keen eye on the
> City of Ottawa tree dataset after seeing a project showing all the
> fruit-bearing trees in the city.
>
> http://data.ottawa.ca/dataset/tree-inventory-street-trees
>
> The dataset provided has all the common names for the species of tree (eg.
> Colorado Spruce). To make it a little more comprehensive, I've added the
> Latin names for the genus and species for most of the trees myself, along
> with the leaf type and cycle.
>
>
> I've added a few trees to the map as a preview of the data being imported.
> (The remainder will be added using and import account)
>
> http://www.openstreetmap.org/#map=17/45.47443/-75.45005 (North of Innes,
> East of Trim) <http://www.openstreetmap.org/#map=17/45.47443/-75.45005>
>
> <http://www.openstreetmap.org/#map=17/45.47443/-75.45005>
> http://www.openstreetmap.org/node/4937732175 (One specific node example)
> <http://www.openstreetmap.org/#map=17/45.47443/-75.45005>
>
>
> More details are provided in the wiki.
>
> https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Trees
> <https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Trees>
>
>
> Would love to hear some feedback and hopefully there are no issues to be
> found.
>
>
> Cheers,
>
> Kyle
>
> ___
> 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] Airport codes

[Denis Carriere]

Too easy! Thanks Sebastien

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jun 8, 2017 at 12:40 PM, Sébastien Robitaille <
sebast...@robitaille.info> wrote:

> http://wiki.openstreetmap.org/wiki/Key:iata and http://wiki.
> openstreetmap.org/wiki/Key:icao
>
> On Thu, Jun 8, 2017 at 12:00 PM James <james2...@gmail.com> wrote:
>
>> Does anyone know if there is a tagging mechanism for airport codes(IATA &
>> OACI specifically)?
>>
>> Example: Toronto airport IATA=YYZ and OACI=CYYZ
>> Ottawa IATA=YOW and OACI = CYOW
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> --
> -Sebastien Robitaille
>
> ___
> 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-us] Tracing buildings in US Cities

[Denis Carriere]

Woot! :)

*~~*
*Denis Carriere*

On Mon, May 29, 2017 at 10:39 AM, Jinal Foflia <fofliaji...@gmail.com>
wrote:

> Hi everyone,
>
> This is Jinal Foflia and I work with the Mapbox's Data team [0]. Our
> team is planning to work on improving the coverage of building footprints
> in the following cities:
>
>
>- Jacksonville, Florida
>- Memphis, Tennessee
>- Louisville, Kentucky
>
>
> Let us know if there are any ongoing/probable imports happening in any of
> these cities? If so, please post back on this thread, this will be really
> helpful!
>
> [0] http://wiki.openstreetmap.org/wiki/Mapbox#Mapbox_Data_Team
>
> Cheers,
> Jinal Foflia
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] HDYC, login requirement and "privacy"

[Denis Carriere]

+1 both James & Michal's comments.

Thanks Michal for bringing up this undiscussed topic to the mailing list.

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, May 4, 2017 at 3:42 PM, James <james2...@gmail.com> wrote:

> What Michal said. Any body can download the OSM data and run the same
> analysis. You agreed to contribute to OSM, if you want your online
> footprint to be non-existant: unplug your internet.
>
> On Thu, May 4, 2017 at 3:33 PM, Michał Brzozowski <www.ha...@gmail.com>
> wrote:
>
>> Many know Pascal Neis' site HDYC which displays detais about an OSM
>> user, like first created node, activity area, edit stats and so on:
>>
>> http://hdyc.neis-one.org/
>>
>> Today to view any stats of a user you have to login with OSM.
>> Pascal replied to me that this is related to this discussion on the
>> German users forum:
>>
>> https://forum.openstreetmap.org/viewtopic.php?id=57813
>>
>> I don't like the idea how this was never introduced and discussed
>> outside of the German forum.
>> I think that such "privacy" measures are futile and go against the
>> spirit of OSM - transparency.
>>
>> Maybe this is due to some "moral panic" in Germany revolving around
>> privacy, just like StreetView ban - except it's made clear that your
>> edits are public and you agree to it!
>>
>> Michał
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
>
> --
> 外に遊びに行こう！
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Available Building Footprints Date: March 28, 2017 at 2:06:33 AM PDT

[Denis Carriere]

Instead of having tons of different people trying to attempt loading all of
these 8 Million buildings, we shoul collectively start an import proposal
(OSM wiki, draft a plan, set up tasking managers, pre-process data, host
entire dataset, etc...).

The best/easiest solution we (OSM Ottawa) did for importing 1M+ buildings
was to convert the data into GeoJSON and then convert them into VectorTiles
using Tippecanoe [0] and host them using our own custom server (Micro Data
Service [1]) which hosts those vector tiles into OSM & GeoJSON. After all
the "hard work" is done.. you can simply add those small chunks of data
with JOSM using any Tasking Manager by adding the URL [2] in Extra
Instructions. An example of a final OSM tile would look like this [3] which
would be ready to import (semi-manually).

There's also integration with QA-Tiles [4] to prevent loading any duplicate
data (this feature requires continuously loading the most current QA-Tile
during the import process).

*Summary: *Before anyone attempts to import this data, we need to create a
plan first. I'm more than willing to help out, but this would be a large
task and would need to be done collectively as a group.

[0] https://github.com/mapbox/tippecanoe
[1] https://github.com/osmottawa/micro-data-service
[2]
http://localhost:8111/import?new_layer=true=https://data.osmcanada.ca/{z}/{x}/{y}/ottawa-buildings.osm
[3] https://data.osmcanada.com/15/9478/21019/ottawa-buildings.osm
[4] https://osmlab.github.io/osm-qa-tiles/

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Tue, Mar 28, 2017 at 11:00 AM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> Hi Nathan:
>
> I've got pretty beefy hardware, but the "Bay Area" shapefile pointed to by
> your recent post chokes my JOSM to a gasping strangle:  >3.7 million
> objects?!  These need to be broken up further to smaller files, to either
> the county level or even smaller to a sub-county level, in a sane way.  You
> may as well save them as .osm files (and host them on some other place
> besides a Microsoft cloud), as shapefiles still remain a "foreign" (though
> importable) format within OSM.
>
> SteveA
> California
>
>
> > On Mar 28, 2017, at 5:00 AM, talk-us-requ...@openstreetmap.org wrote:
> >
> > https://wiki.openstreetmap.org/wiki/Available_Building_Footprints
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] Telenav mapping turn restrictions

[Denis Carriere]

That's unfortunate to hear, I'm not shocked to hear that since we've since
this behavior in Ottawa as well (without investigating too much, I've seen
some questionable road edits from Telenav in the past).

+1 Andrew, thanks for sharing.

I'm sure Telenav as a company means well in their edits and they aren't
purposely trying to vandalise OSM, but might be good to pass down a word to
their OSM editors to be careful when they attempt to delete existing data
(especially if it clearly shows that a local mapper edited the area with
high details).

On Mar 25, 2017 11:53 PM, "Andrew Lester"  wrote:

> I just discovered that user georges_telenav has been mapping turn
> restrictions in the Victoria, BC area. While some of them seem valid, there
> are hundreds of right-turn restrictions that can't possibly be based on
> either Mapillary or OpenStreetView as stated below, because these
> restrictions simply don't exist in reality. Here's an example:
> http://www.openstreetmap.org/relation/7014602
>
> I don't know about the rest of Canada, but at least in BC, this type of
> turn is perfectly legal unless otherwise indicated. Most drivers would use
> the link road and I'd expect routers should always prefer that, but there's
> nothing wrong if a driver gets past the link road and then changes their
> mind and wants to turn right. I can think of a handful of locations around
> town where there may be a sign explicitly forbidding this or at least
> implying it (e.g. "only left turn"), but the vast majority of the instances
> that this user has mapped do not have such signage. I'm in the process of
> cleaning all these up, but I'm worried there may be thousands more of these
> all over the place outside my immediate region.
>
> However, what I discovered while cleaning these up is even more
> disturbing. This is a region with significant growth, and there are
> frequent changes and additions to the road network. So far, I've discovered
> several cases where a reconfigured intersection or new road I had carefully
> mapped by GPS has been obliterated and replaced with an old configuration,
> apparently based on out-of-date aerial imagery. I take pride in mapping
> these changes as soon as possible after they're completed so end-users have
> the most reliable data (and I often mention this to people as one of the
> benefits of using OSM data in applications), so it's disappointing to see a
> distant armchair mapper destroy this careful on-the-ground work based on
> faulty assumptions and out-of-date imagery. I've also seen Telenav mappers
> adding residential roads that are clearly driveways and making edits
> without properly aligning aerial imagery, so I'm not exactly filled with
> confidence that they should be making widespread changes like they are.
>
> Martijn, I think Telenav needs to stop what they're doing and have a
> careful discussion with us about their plans and editing procedures before
> making any more edits. At least in my area, their edits have not only
> failed to improve the dataset, but in a number of cases has actually
> degraded it. Something needs to be done about this before things go too
> far. I already have a lot of cleanup work ahead of me, and I'd like to
> avoid this happening again in the future (at least by Telenav).
>
> Andrew
> Victoria, BC, Canada
>
> --
> *From: *"James" 
> *To: *"John Marshall" 
> *Cc: *"talk-ca" 
> *Sent: *Wednesday, October 19, 2016 11:44:53 AM
> *Subject: *Re: [Talk-ca] Telenav mapping turn restrictions
>
> Yeah no one really wants to do that, except maybe mapbox's india
> contractors
>
> On Oct 19, 2016 2:43 PM, "John Marshall"  wrote:
>
>> Make sense to me. Adding turn restrictions is something I don't want to
>> add.
>> Happy to see all my Mapillary and OpenStreetView imagery being used to
>> help improve the map.
>>
>> John
>>
>> On Tue, Oct 18, 2016 at 9:24 AM, Begin Daniel  wrote:
>>
>>> Go with the recommended scheme as described on the wiki.
>>>
>>> Daniel
>>>
>>>
>>>
>>> *From:* Martijn van Exel [mailto:m...@rtijn.org]
>>> *Sent:* Monday, 17 October, 2016 23:53
>>> *To:* Talk-CA OpenStreetMap
>>> *Subject:* [Talk-ca] Telenav mapping turn restrictions
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I wanted to give you a heads up that my colleagues on the Telenav map
>>> team are starting work on adding turn restrictions in Toronto, Montréal,
>>> and later on also Vancouver, Ottawa and Calgary. We are using
>>> OpenStreetView and Mapillary as sources. If you have any questions or
>>> concerns, please reach out to me and we will address it right away.
>>>
>>>
>>>
>>> For conditional (time-restricted) turn restrictions, we intend to use
>>> the schema described in http://wiki.openstreetmap.org/wiki/Conditional_
>>> restrictions. We encounter a more complex mapping of conditional turn
>>> restrictions sometimes, where 

Re: [Talk-ca] Municipal boundaries

[Denis Carriere]

+1 Kevin again :)

Boundaries are a MUST if ever you want better geocoding.

We just need to deconflict the boundaries that are different from StatsCan
& the local municipalities (these boundaries should be "authoritative" if
they exist).

Remember, not all townships have a full GIS team working for them, there's
going to be many areas in Canada that StatsCan does have the "best" data.

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Tue, Mar 7, 2017 at 1:38 PM, kevinfarrugia <kevinfarru...@gmail.com>
wrote:

> Sorry JP, just talking from my experience in Ontario where they generally
> (at least in Southern Ontario) follow legal boundaries.
>
> In the end, whoever does it will need to have knowledge of the area and
> how boundaries work in that province/locality, but boundaries are
> definitely important for geocoding and analysis and would remove the need
> for extremely redundant addr tags that are used for cities.
>
>
> Sent from my Samsung Galaxy smartphone.
>
>  Original message 
> From: "J.P. Kirby" <webmas...@the506.com>
> Date: 2017-03-07 1:21 PM (GMT-05:00)
> To: James <james2...@gmail.com>
> Cc: Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
> Subject: Re: [Talk-ca] Municipal boundaries
>
> And even then, not all CSDs are municipalities. In Nova Scotia for
> instance they have "county subdivisions" which have no legal standing at
> all and are just StatsCan creations.
>
> I'd suggest boundaries of actual municipalities are worthy of being added
> into OSM, but not all CSDs fit that bill.
>
> Sent from my iPhone
>
> On Mar 7, 2017, at 2:10 PM, James <james2...@gmail.com> wrote:
>
> CSDs are suppose to represent city/town limits (observable as usually
> there's a sign that says Welcome to X or Sorry to see you leave X), but
> they have been rounded off to look nice and may not reflect what it is in
> reality
>
> On Tue, Mar 7, 2017 at 1:05 PM, Stewart C. Russell <scr...@gmail.com>
> wrote:
>
>> On 2017-03-07 10:36 AM, Bjenk Ellefsen wrote:
>> >
>> > … Any more thoughts?
>>
>> If you're planning to import/add abstract statistical boundaries, rather
>> than those defined by municipal boundaries, then I'd suggest that they
>> don't belong in OSM.
>>
>>  “Contributions to OpenStreetmap should be:
>>1. Truthful - means that you cannot contribute something you have
>> invented.
>>2. Legal - means that you don't copy copyrighted data without
>> permission.
>>3. Verifiable - means that others can go there and see for
>> themselves if your data is correct.
>>4. Relevant - means that you have to use tags that make clear to
>> others how to re-use the data
>>
>>   When in doubt, also consider the "on the ground rule": map the world
>>   as it can be observed by someone physically there.”
>>
>>  — How We Map <https://wiki.openstreetmap.org/wiki/How_We_Map>
>>
>> Unless CSDs are physically observable, they are too abstract for OSM.
>>
>>  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

Re: [Talk-ca] Municipal boundaries

[Denis Carriere]

I just want to re-enforce the comment that Kevin Farrugia made.

Boundaries are one of the most complex features to add in OpenStreetMap.
They usually consist of relations that share borders with
roads/rivers/other boundaries.

If ever there is an import of boundaries, the users doing the import have
to be VERY experienced with using relations and understand how they work.

This goes way beyond adding simple building footprints :)

I'm sure this can be accomplished with the group of people who replied to
this thread.

Documentation is key for this type of work.

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Tue, Mar 7, 2017 at 10:36 AM, Bjenk Ellefsen <bjenk.ellef...@gmail.com>
wrote:

> James, it looks to me those differences are the result of a simplification
> applied on the processing side.
>
> And I also agree that good enough is usually more problems down the road.
> We should adopt a standard. The only one I know of for the country is the
> SGC and Paul is pointing out to an example of how Provinces have defined
> boundaries.
>
> We probably should look at a standard though if we wish to produce OSM
> analysis that is consistent and reproducible. The problem I foresee with
> the use of different and variable boundaries is that it will make OSM data
> use inconsistent and not accurate.
>
> What I understand form our discussion is that I should do more research on
> what provinces are using and document this before doing anything and report
> here. Thanks everyone for the feedback! Any more thoughts?
>
>
>
>
>
> On Tue, Mar 7, 2017 at 10:11 AM, James <james2...@gmail.com> wrote:
>
>> Quebec's Open Data portal just points to the city portals which each have
>> their own license(usually CC-BY)
>>
>> https://www.donneesquebec.ca/fr/
>>
>> On Tue, Mar 7, 2017 at 9:42 AM, James <james2...@gmail.com> wrote:
>>
>>> We also have to think if we are going with "good enough" when we
>>> want better the work that will be doubled to make the boundaries better.
>>>
>>> On Tue, Mar 7, 2017 at 9:38 AM, Paul Ramsey <pram...@cleverelephant.ca>
>>> wrote:
>>>
>>>> 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 <james2...@gmail.com> 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 <
>>>>> bjenk.ellef...@gmail.com> 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 <james2...@gmail.com> wrote:
>>>>>>
>>>>>>&

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[Denis Carriere]

Thanks Stewart for bringing this information forward.

We will surely make sure to spread the announcement locally here in Ottawa.

Enjoy the weekend!

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Sat, Mar 4, 2017 at 1:01 AM, James <james2...@gmail.com> wrote:

> Thank you scruss for digging up the meeting notes :)
>
> On Mar 4, 2017 12:40 AM, "Heather Leson" <heatherle...@gmail.com> wrote:
>
> Fantastic. Happy open data day!
>
> On 4 Mar 2017 04:12, "John Marshall" <rps...@gmail.com> wrote:
>
>> Great news
>>
>> On Mar 3, 2017 9:16 PM, "Stewart C. Russell" <scr...@gmail.com> wrote:
>>
>>> I just got access to the OSMF LWG draft minutes from yesterday, and I
>>> have good news: Ottawa ODL 2.0 data *can* be included in the OSM
>>> database.
>>>
>>> The minutes link - https://docs.google.com/docume
>>> nt/d/1KyTLbQWSmo1rdoppqlFGTB3by-qVAzjLo_LPml3Ri9Y/edit - is still draft
>>> so may not be generally readable, so I've included the text in full below:
>>>
>>> *5. Statement on Ottawa Open Data Licence Version 2.0 compatibility*
>>>
>>> Approval of the following statement:
>>>
>>> ---
>>>
>>> The LWG has been asked to determine the compatibility of Ottawa Open
>>> Data, Licence Version 2.0 (Ottawa ODL 2.0) with the ODbL 2.0 in conjunction
>>> with importing so licensed data. The text of the Ottawa ODL 2.0 can be
>>> found here
>>> <http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0>
>>> *http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0*
>>> <http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0>
>>>
>>> The Ottawa ODL 2.0 is a localised version of the OGL Canada
>>> <http://open.canada.ca/en/open-government-licence-canada>
>>> *http://open.canada.ca/en/open-government-licence-canada*
>>> <http://open.canada.ca/en/open-government-licence-canada> which in turn
>>> is loosly based on the UK OGL. The changes relative to the OGL Canada due
>>> to localisation are the licensor (the City of Ottawa) and reference to the
>>> definition of "personal information" as defined in the "Ontario Municipal
>>> Freedom of Information and Protection of Privacy Act",
>>>
>>> The LWG has determined
>>>
>>>-
>>>
>>>that the attribution requirements of the Ottawa ODL 2.0 can be met
>>>by adding the required text to the wiki contributor page and 
>>> corresponding
>>>changeset source attribute values, and that there is no downstream
>>>attribution requirement,
>>>-
>>>
>>>that we are not using "Personal Information" as defined in the
>>>licence and referenced legislation,
>>>
>>> and that so licensed material can be included in the OpenStreetMap
>>> dataset and distributed on ODbL 1.0 terms.
>>>
>>> In the past the local variants of the OGL Canada have varied widely and
>>> have in some cases included additional terms that have made them
>>> incompatible with the ODbL and in some instances non-open. For this reason
>>> we are not making a blanket statement on other such localised versions of
>>> the OGL at this point in time and will continue to review them on a case by
>>> case base.
>>>
>>> ---
>>>
>>> Approved with 4 yes, 1 abstain.
>>>
>>>
>>> I've also updated the wiki page.
>>>
>>> Have a great weekend!
>>>  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
>>
>>
> ___
> 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

[Talk-ca] Ottawa Buildings & Addresses [Statistics Canada project]

[Denis Carriere]

Good day everyone,

Thanks for everyone who provided feedback related to the Ottawa import
plan, all of the concerns & issues have been resolved.

Going to officially announce that we will be starting the Ottawa building &
address import.

*OSM Wiki - Import Plan*
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan
<https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan#Explicit_permission>

*Explicit Permission from the City of Ottawa*
https://wiki.openstreetmap.org/wiki/Canada:Ontario:
Ottawa/Import/Plan#Explicit_permission

*Video instruction (**YouTube)*
https://youtu.be/OkFCkPBR7PA

*City of Ottawa's open datasets*
http://data.ottawa.ca/dataset/urban-buildings
http://data.ottawa.ca/dataset/addresspoints

*Tasking Manager #37 (private - invite only)*
http://tasks.osmcanada.ca/project/37

Cheers,

*~~*
*Denis Carriere*

*GIS Software & Systems SpecialistOSM Account: @DenisCarriere
<https://www.openstreetmap.org/user/DenisCarriere>*
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Denis Carriere]

There's been a lot of discussion on the license, however has anyone read
the documentation on the import yet? Could the OSM Talk-CA provide any
feedback on this, that way once the license is sorted out we can start
immediately afterwards.

http://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan

For those who are more the visual type, we've created a YouTube video
explaining the workflow proposed.

https://www.youtube.com/watch?v=OkFCkPBR7PA

If there's no feedback related to the Import Wiki page we're going to
assumed this section of the import is approved.

Cheers,

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Mon, Jan 23, 2017 at 12:45 AM, Paul Norman <penor...@mac.com> wrote:

> On 1/22/2017 9:06 AM, James wrote:
>
>> So if I understand correctly Paul, CC0 or any other license would require
>> permission as a bypass to the license, even though it would be considered
>> compatible with ODBL.
>>
>
> No. CC0 is compatible with the ODbL, so you can just go ahead and use the
> data*, subject to any conditions the community has developed around imports.
>
> * There could be exceptional circumstances in some cases.
>
>
> ___
> 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-us] [Talk-ca] destination:street

[Denis Carriere]

I've also been using Mapbox's document as reference for exit signs and off
ramps. I believe it makes a lot more sense to divide the tags into separate
known entities instead of adding all of values into a single destination
tag.

The OSM tags seemed to be well described in their docs:

I am supportive of the *destination:street *tag.

destination tag refers to the place that the way exiting from the freeway
leads to.
destination:ref is the reference of the roads directly ahead.
destination:ref:to is to specify the reference of a major highway ahead.
destination:street refers to the main street the way exiting from the
freeway leads to.


*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

>
> On Thu, Jan 19, 2017 at 8:28 PM, Kevin Farrugia <kevinfarru...@gmail.com>
> wrote:
>
>> Hey Martijn & everyone else,
>>
>> The bulk of destination:street was added beginning with Mapbox's "Mapping
>> exit numbers and destinations in Canada", which described the methods to
>> use [https://github.com/mapbox/mapping/issues/220]  Since then, most of
>> us (me included) in Southern Ontario have just continued that method on the
>> map.  They used to be combined in the destination tag, but they've since
>> been separated out, so this is still actively used.  The documentation I
>> used to better understand it was on the Exit Info page:
>> http://wiki.openstreetmap.org/wiki/Exit_Info
>>
>> I could see it having a bit more usefulness for routing purposes, but
>> you're on that side of the equation, not me :)
>>
>> -Kevin (Kevo)
>>
>> On Thu, Jan 19, 2017 at 8:00 PM, Martijn van Exel <m...@rtijn.org> wrote:
>>
>>> Hi all,
>>>
>>> The Telenav mapping team noticed quite a few destination:street tags on
>>> (mostly) motorway_link off-ramps in Canada. This is an undocumented sub-tag
>>> of the destination tag so I am curious how it is being used and if there is
>>> some sort of consensus that is documented somewhere else than the OSM wiki.
>>>
>>> An Overpass query surfaced 1883 cases, http://overpass-turbo.eu/s/ln2
>>>
>>> Looking at a random one, http://www.openstreetmap.org/way/34154734 /
>>> http://openstreetcam.org/details/10767/4194 — I think in the US we
>>> would just map this as destination=Carman Road;Iriquois and
>>> destination:ref=1
>>>
>>> So my question is whether this is some relic of a past practice, or is
>>> this actively used and encouraged mapping practice and if so, where should
>>> it be documented? (https://wiki.openstreetmap.or
>>> g/wiki/Proposed_features/Destination_details seems to be a good
>>> candidate.)
>>>
>>> We’re happy to help improve these tags based on OSC / Mapillary data but
>>> I wanted to make sure first that this is the way you all want to go.
>>>
>>> Happy mapping,
>>>
>>> Martijn van Exel
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> talk...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>
>> ___
>> Talk-ca mailing list
>> talk...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] destination:street

[Denis Carriere]

I've also been using Mapbox's document as reference for exit signs and off
ramps. I believe it makes a lot more sense to divide the tags into separate
known entities instead of adding all of values into a single destination
tag.

The OSM tags seemed to be well described in their docs:


   - destination tag refers to the place that the way exiting from the
   freeway leads to.
   - destination:ref is the reference of the roads directly ahead.
   - destination:ref:to is to specify the reference of a major highway
   ahead.
   - destination:street refers to the main street the way exiting from the
   freeway leads to.

I am supportive of the *destination:street *tag.


*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

On Thu, Jan 19, 2017 at 8:28 PM, Kevin Farrugia <kevinfarru...@gmail.com>
wrote:

> Hey Martijn & everyone else,
>
> The bulk of destination:street was added beginning with Mapbox's "Mapping
> exit numbers and destinations in Canada", which described the methods to
> use [https://github.com/mapbox/mapping/issues/220]  Since then, most of
> us (me included) in Southern Ontario have just continued that method on the
> map.  They used to be combined in the destination tag, but they've since
> been separated out, so this is still actively used.  The documentation I
> used to better understand it was on the Exit Info page: http://wiki.
> openstreetmap.org/wiki/Exit_Info
>
> I could see it having a bit more usefulness for routing purposes, but
> you're on that side of the equation, not me :)
>
> -Kevin (Kevo)
>
> On Thu, Jan 19, 2017 at 8:00 PM, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Hi all,
>>
>> The Telenav mapping team noticed quite a few destination:street tags on
>> (mostly) motorway_link off-ramps in Canada. This is an undocumented sub-tag
>> of the destination tag so I am curious how it is being used and if there is
>> some sort of consensus that is documented somewhere else than the OSM wiki.
>>
>> An Overpass query surfaced 1883 cases, http://overpass-turbo.eu/s/ln2
>>
>> Looking at a random one, http://www.openstreetmap.org/way/34154734 /
>> http://openstreetcam.org/details/10767/4194 — I think in the US we would
>> just map this as destination=Carman Road;Iriquois and destination:ref=1
>>
>> So my question is whether this is some relic of a past practice, or is
>> this actively used and encouraged mapping practice and if so, where should
>> it be documented? (https://wiki.openstreetmap.or
>> g/wiki/Proposed_features/Destination_details seems to be a good
>> candidate.)
>>
>> We’re happy to help improve these tags based on OSC / Mapillary data but
>> I wanted to make sure first that this is the way you all want to go.
>>
>> Happy mapping,
>>
>> Martijn van Exel
>>
>>
>> ___
>> 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] New Innovative Map Company

[Denis Carriere]

This project was truly an awesome journey with Bradon, it was really
exciting to work together on KrateLabs and the final map products look
amazing!

Also a big thanks to Shopify & Mapbox <3 for creating awesome tools that
made this entire project happen.

Can't wait for the next KrateLabs mapping ideas! :)

Cheers,

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Sun, Nov 6, 2016 at 1:17 PM, Heather Leson <heatherle...@gmail.com>
wrote:

> So great!  Now I need to not live on the road so that I have a wall for it.
>
> Congratulations
>
> heather
>
> Heather Leson
> heatherle...@gmail.com
> Twitter/skype: HeatherLeson
> Blog: textontechs.com
>
> On Sun, Nov 6, 2016 at 3:36 PM, Bradon Levalds <bleva...@gmail.com> wrote:
>
>> Hey Stewart,
>>
>> Thanks again. I will ensure the correct attributions are visible on both
>> digitally and printed on the labels we place on the maps themselves.
>>
>> Thanks,
>> Bradon.
>>
>> > On Nov 5, 2016, at 1:21 PM, Stewart C. Russell <scr...@gmail.com>
>> wrote:
>> >
>> > On 2016-11-05 12:43 PM, Bradon Levalds wrote:
>> >>
>> >> This lasering allows only light to pass through the etched artwork
>> which
>> >> frosts, creating a unique, contemporary and detailed design of any
>> >> location in the world with just the click of a button.
>> >
>> > These look really nice! I bet it took a load of trial and error to get
>> > the engraving just so. Having spent a good bit of time laser cutting and
>> > etching acrylic, the results look spectacular when you've got the
>> > settings dialled in.
>> >
>> > Hope you've got the attribution* somewhere on the label!
>> >
>> > Stewart
>> >
>> > *:
>> > https://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_
>> like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
>> >
>> > ___
>> > 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Road route relations: network tag

[Denis Carriere]

I agree with Martjin, those tags should be corrected to *network*=CA:ON

Good catch!

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Thu, Oct 27, 2016 at 6:04 PM, Martijn van Exel <m...@rtijn.org> wrote:

> Hi all,
>
> My mapping colleagues (not me, I only map in my spare time :)) noted that
> there are some irregular network tags on highways in Canada. The usual
> hierarchical notation[1] is in place in many relations, but we encountered
> deviations from that where instead of the colon separator an underscore is
> used, so for example instead of CA:ON we see ca_on, and some variations on
> that.
>
> We are happy to (help) clean that up but didn't want to do so without
> consulting you. Is there some local convention that we are unaware of? Can
> we provide a dump of the affected relation IDs so we can fix them together?
> It's about 400 relations in total, mostly in Ontario.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format -
> it has a Canada example!
>
> Martijn van Exel
> http://mvexel.github.io/
>
> ___
> 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] [Imports] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Denis Carriere]

Christoph,

At the moment the Ottawa building footprint dataset is not on any official
portal other then being shared on a public Amazon S3 Bucket.

You can download the file here:

https://s3.amazonaws.com/statscan/ottawa-buildings.geojson

The data doesn't contain any specific tags, only the following:

*source: *City of Ottawa
*building: *yes


Cheers,




*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Mon, Oct 24, 2016 at 2:13 PM, James <james2...@gmail.com> wrote:

> As stated, multiple times on this list already: the city of Ottawa gave
> data to Statistics Canada. Statistics Canada gave us (amazon cloud link)
> data, which is just building outlines.
>
> In case you are in doubt this project is actually happening or not (and I
> am just making the whole thing up):
> http://www.statcan.gc.ca/eng/crowdsourcing
> on facebook(https://www.facebook.com/StatisticsCanada):
> https://www.facebook.com/StatisticsCanada/photos/a.168165143295004.32908.
> 125909694187216/996642833780560/?type=3
> https://www.facebook.com/StatisticsCanada/photos/a.168165143295004.32908.
> 125909694187216/995955653849278/?type=3
> https://www.facebook.com/StatisticsCanada/photos/a.168165143295004.32908.
> 125909694187216/994856040625906/?type=3
>
> As well as Bjenk(current project lead on this) posting on the mailing list
> back in july:
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-July/007034.html
>
>
> On Mon, Oct 24, 2016 at 2:00 PM, Christoph Hormann <chris_horm...@gmx.de>
> wrote:
>
>> On Monday 24 October 2016, Stewart C. Russell wrote:
>> >
>> > The new data is pretty close, though. Anyone need a
>> > demo/writeup/picture, or are people generally happy with the
>> > provenance of the data now?
>>
>> Could you please clarify what the alleged source of the building data to
>> be imported is?
>>
>> What is shown in
>>
>> https://gist.github.com/scruss/5a3f469c47df5d27fdba28258c273b45
>>
>> does not match geometry-wise.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
>
>
> --
> 外に遊びに行こう！
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Imports] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Denis Carriere]

I agree as well, we should be careful not to delete the history of the OSM
features.

It does take longer in the dense areas of the city, however in the rural
areas it's not a concern since there just isn't any buildings what so ever.

Great comment & concern,

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Fri, Oct 21, 2016 at 2:17 PM, James <james2...@gmail.com> wrote:

> I agree with Pavel (about the guidelines being considered to be followed
> to a T, when guidelines by definition are what should be done)
>
> As for Ottawa relying on external sources to collect data/correct the
> data. Ottawa has a GIS team and surveyors and do said work internally. So
> they do own 100% of the data they are outputting.
>
> Pavel, I don't think it's a matter of keeping less accurate data vs not
> keeping it, it's more keeping the history attached to the object. If
> someone put many hours into initially making a map (say from 2008) and
> someone comes a long 8 years later and deletes it, you are no longer
> credited to the contribution of that object(I can see, now, why people were
> angry)
>
> On Fri, Oct 21, 2016 at 2:06 PM, Pavel Machek <pa...@ucw.cz> wrote:
>
>> Hi!
>>
>> >   Commitment to follow the rules
>> >
>> > Please ensure that any documentation contains a commitment to follow the
>> > Import/Guidelines
>> > <https://wiki.openstreetmap.org/wiki/Import/Guidelines> and Automated
>> > Edits code of conduct
>> > <https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct>.
>> > These are non-negotiable parts of participation in OSM imports. The
>> > Ottawa import very definitely falls under the definition of an Automated
>> > Edit.
>>
>> Actually... I don't think this should be requirement. Import
>> guidelines are not a holy text, people should follow them, but...
>> what is next. Should they also include a poem explaining how
>> import guidelines are great and make openstreetmap more useful?
>>
>> > While it is generally considered that OGL-CA is acceptable to OSM, the
>> > lingering third-party waiver issue is troubling. As the City of Ottawa
>> > almost certainly relied on third parties to collect and correct the
>>
>> While you may find it troubling, requiring such waivers is going to
>> make imports impossible. (And openstreetmap useless).
>>
>> >   Data deletion
>> >
>> > While you will likely be able to show that some imported outlines are
>> > more accurate than existing tracings, please don't delete/overwrite
>> > community contributions. Also, under *no* circumstances delete
>>
>> So you suggest we keep less accurate data in openstreetmap,
>> because...?
>>
>>
>> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.c
>> z/~pavel/picture/horses/blog.html
>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>>
>
>
> --
> 外に遊びに行こう！
>
> ___
> 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] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Denis Carriere]

Stewart,

The process was a success for me, the only issue was the data was bad...
I've been involved in importing some of the GNS data and it was a great set
up Pierre and other OSM members set up.

Bad data goes in, bad data comes out.

Thankfully we have good data provided by the City of Ottawa that was
created by GIS professionals.

On Oct 20, 2016 12:54 AM, "Stewart C. Russell"  wrote:

> Hi Denis,
>
> > There's been countless amounts of Tasking Manager's that have been set
> > up for importing GNS (towns & villages) in Africa, I believe all of them
> > were only point data and have been very successful.
>
> While it's not a reflection on tasking manager, the African village GNS
> import recently made “Worst of OSM”: “Look at these nicely arranged
> Nigerian villages”
>  these-nicely-arranged-nigerian-villages>.
> There's no way that these villages are arranged in nice neat rows and
> columns exactly one minute of arc apart …
>
>  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

Re: [Talk-ca] [Import] Ottawa Buildings & Addresses [Statistics Canada project]

[Denis Carriere]

Hey Steve,

James already answered a few of your comments, however I can expand a bit
more on one of your questions/comment about the TM and the OSM tiles.


> Are there examples of tasking manager coordinated building imports that
> the community considers a success? If so how does this plan compare to what
> has worked well. (This isn't specifically directed at James)
> I haven't yet looked at samples of the .OSM files


There's been countless amounts of Tasking Manager's that have been set up
for importing GNS (towns & villages) in Africa, I believe all of them were
only point data and have been very successful.

This task is attempting to import polygon datatypes which can be very
problematic for tile based semi-manual imports.

Anyone who's ever attempting to pre-process GIS data into individual tiles
knows how much a pain it can become, especially when you have a large
dataset and multiple scales (zoom 13-14-15).

Since we are trying to integrate the data directly into the Tasking
Manager, we want the users to be able to split the tiles in the event that
the individual task is too large, this is why we wanted to have the data
dynamic.

Using a lot of awesome tools created by Mapbox such as tippecanoe
<https://github.com/mapbox/tippecanoe> [0] & turfjs <http://turfjs.org/> [1]
& geojson2osm. We are able to dynamically create OSM tiles for the Tasking
manager by simply creating a simple Vector Tile dataset (.mbtiles) and
using our Micro Data Service[2] which was created by OSMCanada.

This web based service creates a set of URL's that can be loaded into the
Tasking Manager or downloaded manually.

*URL Schemas*

https://data.osmcanada.ca/{z}/{x}/{y}/.(osm|geojson)
https://data.osmcanada.ca/15/9501/21037/ottawa-buildings.osm
https://data.osmcanada.ca/15/9501/21037/ottawa-buildings.geojson

Add this URL in *Extra Instructions* for your Tasking Manager

http://localhost:8111/import?new_layer=true=https://
data.osmcanada.ca/{z}/{x}/{y}/ottawa-buildings.osm

Let me know if anyone needs more details or want to test out a dataset of
their own, the only input required is a GeoJSON.

Cheers,

[0]: https://github.com/mapbox/tippecanoe
[1]: http://turfjs.org/
[2]: https://github.com/osmottawa/micro-data-service

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Wed, Oct 19, 2016 at 9:58 PM, Steve Singer <st...@ssinger.info> wrote:

> On Wed, 19 Oct 2016, James wrote:
>
> Seems like a good enough time like any other to talk about the import of
>> Ottawa buildings and addresses
>> into OpenStreetMap.
>>
>> Documentation is available here:
>> https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan
>>
>
> A few comments
>
> * Replacing Building Geometries - I don't like the policy of replacing
> existing building geometries with imported ones.  I feel that large scale
> replacement of hand traced work with automated/imported work will
> discourage future mappers.  Also sometimes which is 'better' is a matter of
> opinion and if a few mappers are replacing hundreds or thousands of
> buildings in a short period of time it is hard to have discussion on an
> individual building basis.   I don't have issues with a mapper manually
> changing or replacing the geometries but the bulk non-traced nature
> concerns me. I have heard numerous complaints over the years from mappers
> who traced lakes manually only to see them replaced by canvec imported
> lakes.
>
> * Notes - How many 'What is the address of this house?' notes do we think
> this is going to generate? Adding a few dozen notes in the Ottawa area
> isn't an issue but if this process adds hundreds of notes that require
> manual survey then I'm not sure that is better than just skipping the
> address(but this could be discussed)
>
> I think the import plan needs to talk more about what the expected
> 'quality' is. I am not talking about the quality of the data but the
> quality of the merging
>
> For example:
> * Do we expect that before uploading a tile all JOSM validator errors get
> cleared on the objects being uploaded?
> * If an existing object such as a road, alley or stream runs through the
> geometry of the building then will the pre-upload validation process
> require that this be fixed
>
>
> Part of the problem with the Canvec imports is that quality is very much a
> factor of who imported a tile in a particular area.  We never really came
> up with minimum standards for the validation and repair requirements. I
> think a checklist of specific types of problems that we expect will need
&g

Re: [Talk-ca] City of Ottawa imported buildings & addresses

[Denis Carriere]

Ok this Ottawa reverting process is getting out of hand now! Frederik
(woodpeck_repair) is reverting entire user history without looking at what
his osm-revert-script is doing.

*Before & After of Revert - More info with photos*
https://gist.github.com/DenisCarriere/581b3dbc6adf36608f470702d0bcc38d

This all started because a "building:level" tag was removed by accident in
Stittsville, it happens, don't cry over it.

As for "lack of discussion" we've been planning this for months and invited
all the local mappers to events & we've also got the license agreement from
the City of Ottawa.

So why are you reverting possibly hundreds of hours of work done by the
local OSM Ottawa group?

If you're only concern is documentation and workflows, then we can easily
provide it, no need for an emergency revert of entire users
histories (LogicalViolinist, Rps333, DenisCarriere) all of them are very
active contributors.

I understand the need of a revert if we are breaking a legal agreement for
data that isn't compatible with the OSM license, but this isn't the case.
We've sent dozens of emails to Talk-CA and the only people interested in
the project was our group, next time people should be more involved in
local Canadian open data effort from our government (StatsCan in
particular).

The data in Ottawa is pitiful compared to other parts of the world, I'm
frankly embarrassed when I look at our OSM maps. We finally have a project
that promotes the use of open data provided by the City of Ottawa and we
have a dedicated group that is willing to put all the hard work to improve
the map in Ottawa, and now weeks of hard work is being totally reverted by
a command line script from @woodpeck_repair.

*Quick survey: *Who is even opposed to a Building Import in Ottawa (rural
areas is a big concern)? If no one is, Frederick can you please stop your
revert process and we can continue working on adding the buildings to
Ottawa. We're all very talented mappers and we can fix our mistakes, we
don't need a full user history revert.

Don't hesitate to reply, we're welcoming comments and concerns.

Thanks,

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Tue, Oct 18, 2016 at 1:53 PM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 10/17/2016 11:59 PM, Frederik Ramm wrote:
> > The person responsible for cleaning up a poor revert should be the
> > person who ran it ;) it's only 30% complete and will run far into the
> > night in my time zone and I'll have to check on it after getting up. I'm
> > confident all will be fixed when you get up tomorrow morning.
>
> Unfortunately the import was larger than expected and the revert drags
> on. Meanwhile, a couple of accounts have been newly created by parties
> unknown ("addxy_imports", "ottawa_import") and these have (accidentally
> or purposefully) interfered with the revert, meaning that it will take
> even longer for me do this right.
>
> I would like to appeal to all involved parties to show some maturity.
> The import was in clear violation of established processes; it must be
> reverted, and then the community can - calmly and without any time
> pressure - decide what they want to do with the data.
>
> I haven't analysed the import in depth but I have seen a couple of
> examples where a perfectly well mapped building was wiped clean and
> replaced with one that was not at all better - this is clearly something
> we don't want to see in an import, it is a technical (or procedural)
> shortcoming that would definitely have been pointed out had there been a
> proper discussion beforehand.
>
> The requirement to talk about imports before you act is not an
> unnecessary bueraucratic hurdle; it is intended to avoid disappointment
> on all sides. An import that fears the broad daylight is probably one
> that should not be attempted at all!
>
> I should maybe have made that clearer in my initial email but I'm acting
> here as a member of the OSMF's data working group in response to a
> legitimate complaint, not as a German mapper seeking trouble. I
> sincerely ask everyone involved to keep calm and let the revert complete
> cleanly.
>
> I see that user LogicalViolinist has already found fields of endeavour
> outside of Canada for the time being.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] The Statistics Canada Project

[Denis Carriere]

Hey AJ,

Thanks for understanding, this project has been discussed many times at the
local OSM Ottawa Meetup and we've proven this method of import is very
efficient on smaller scale projects.

We might of leaned a bit too much on StatsCan to tackle the "legal" part of
it, however everything has been sorted out between the City of Ottawa, OSM
& Open Data license. It might just not be as documented on the internet
since StatsCan doesn't promote the use of internet in their office and work
mostly in an offline environment.

There are two datasets we are currently working with, building footprints &
address points. The address one is currently released under the OpenData
Ottawa portal and the building footprint has been released, however not
available yet under the OpenData portal, they are trying to figure out
which portal to disseminate to.

Currently the TM project is private, log in and we can grant you access.

http://tasks.osmcanada.ca/project/34


*Workflow*


*Step 1:* Select a Tile & Start Mapping

*Step 2:* Edit with JOSM

*Step 3:* Apply an inverse filter to find any existing databuilding=*

*Step 4:* Download data - Found in the *Extra Instructions*

*Step 5:* Add feature or merge new data with existing features *(try not to
delete features)*. Check for any existing buildings that might create
conflicts (keep existing, merge tags or only update building footprint)

*Step 6:* Merge address points to building using JOSM address plugin.

*Step 7:* Click JOSM validate and fix any errors or warnings that appear
before submitting your changset.
*Completion Status*

Since adding all the buildings can take a lot of time uploading a single
changeset and the validation requires having the building footprint +
address be available. We've divided the task into two parts "Done" &
"Validation".
*Done*

Once all the building footprints & address are added, you can mark the tile
as *Done *and the next step would be to validate the tile.
*Validation*

This step will require a lot of time and effort. Here are some of the basic
validation process:

   1. Align Address nodes to the center of the building footprints.
   2. Merge Address nodes with building footprints using the JOSM address
   plugin.
   3. Any buildings that don't have an address (Sheds, garages, etc...)
   either tag them with a specific tag or remove them since it causes
   confusion to clearly identify the primary building.
   4. Replace all building footprints from building=yes with an appropriate osm
   building tag <http://wiki.openstreetmap.org/wiki/Key:building>, we've
   been tagging all the residential houses withbuilding=residential.
   5. Use the validate JOSM process to detect any warnings or errors and
   fix them accordingly. You only need to validate the address & building
   footprints, however you decide to fix other OSM related issues, fill your
   boots!




*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Mon, Oct 17, 2016 at 9:07 PM, AJ Ashton <a...@ajashton.ca> wrote:

> Hi John,
>
> Thanks for the writeup. I think this is the first post that's made it
> fully clear what is going on. As I was re-reading the previous StatCan
> thread earlier today I seemed to be missing something - now I guess it was
> context available to those who attended in-person meetings. I don't think
> it was even clear to the list until now how much in-person community
> discussion has been happening.
>
> Basically the issue is that all the online discussion about this looks to
> have been about the StatCan crowdsourcing half of the project and none at
> all about the building import half. I didn't pay too much attention to the
> original StatCan thread at the time because it so clearly sounded like a
> local mapping project with no large-scale import component.
>
> Unfortunately I no longer live in Ottawa and couldn't have made it to the
> meetings. However I lived there for many years, have done a lot of mapping
> there, and have a continued interest in the area. I would still like to see
> the the building import happen and even help out where I can. But I think
> it's important to do more planning and discussion on this list and the
> imports list, and to take things in smaller and more manageable chunks.
>
> I guess the next step would be to continue on a proper path to import the
> buildings per the guidelines per http://wiki.openstreetmap.org/
> wiki/Import/Guidelines . This would include:
>
> - Wiki documentation of the where the data is, what it contains & its
> license / permissions
> - A plan to conflate with existing data - pres

Re: [Talk-ca] City of Ottawa imported buildings & addresses

[Denis Carriere]

Ok now things are even worse!

*(Frederik Ramm) *just did a mass revert [0] with his revert script [1]
created in 2009 and now we have 20,000+ warnings of empty nodes within a
small section of Ottawa [2].

Not only did *(Frederik Ramm) *undo James commits, but now you've
introduced over 100,000+ warnings scattered across Ottawa which is near
impossible to fix unless we revert the revert.

If you're going to undo someone's commits, at least do it right and not
corrupt the OSM data for the Ottawa community.

Please remove all of the empty nodes you've just created from your poor
revert, have you even looked at what you reverted??

[0]: http://www.openstreetmap.org/changeset/42964959
[1]: https://github.com/woodpeck/osm-revert-scripts
[2]: http://127.0.0.1:8111/load_and_zoom?left=-75.67383;
bottom=45.36758=-75.65186=45.38302

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Mon, Oct 17, 2016 at 2:01 PM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 10/17/2016 07:49 PM, AJ Ashton wrote:
> > All of this sounds like they were planning one something like an online
> > mapping party, not an import of government data. Certainly there is no
> > mention that all existing buildings in Ottawa would be wiped out first.
>
> Which is why I'm reverting this import (and the deletions that went with
> it) now. Not because we shouldn't ever import the data, but because I
> don't want a fait accompli to stand in the way of a serious discussion
> about the matter.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Nunavut place names language

[Denis Carriere]

Also all there is a lot of Canadians from BC, Alberta, Ontario & Quebec
that travel for work to those locations by flight and none of them would
understand the Native names of cities, it would bring a lot of confusion to
visitors.

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Sat, Sep 17, 2016 at 2:12 PM, James <james2...@gmail.com> wrote:

> As john said, the people of nunavut can speak the language, but do they
> write it or read it? If not English would be the more popular option
>
> On Sep 17, 2016 10:10 AM, "John Marshall" <rps...@gmail.com> wrote:
>
>> As someone who does a lot of mapping is in Nunavut.  I think it a great
>> idea to add the Native language. That way someone could make a custom map
>> using Native Languages.
>>
>> However,  I think we should get some feedback from local mappers and
>> other people who use the data, not someone from Toronto. If you look at the
>> Government of Nunavut  website http://www.gov.nu.ca/ It's landing page
>> is in English. So it looks to me that the working Language is English.
>>
>> How will this affect Apps like Maps.me and OsmAnd?
>>
>> I feel the common name should be in English and the Native language if
>> available  added as separate tags.
>>
>> John
>>
>> On Fri, Sep 16, 2016 at 5:43 PM, john whelan <jwhelan0...@gmail.com>
>> wrote:
>>
>>> You realise that the written language is actually European shorthand
>>> which was used to record the verbal language.
>>>
>>> Cheerio John
>>>
>>> On 16 September 2016 at 17:35, James <james2...@gmail.com> wrote:
>>>
>>>> I personally dont mind having it in Native language, but if there is
>>>> going to be changed there should be a corresponding name:en tag as the rest
>>>> of the world can't read it.
>>>>
>>>> One of the reasons I don't mind is: who would possibly use it? People
>>>> in Nunavut, that's who. It should be as accessible to them as possible. If
>>>> they dont speak English it creates a barrier of using the Canadian map. Not
>>>> only that but the northern maps aren't that great as they are even though
>>>> there have been efforts to improve them *cough* rps333 *cough*.
>>>>
>>>> On Sep 16, 2016 5:22 PM, "Andy Townsend" <ajt1...@gmail.com> wrote:
>>>>
>>>>> Hello Canadian mappers!
>>>>>
>>>>> The node and relation for Nunavut are http://www.openstreetmap.org/n
>>>>> ode/305700700 and http://www.openstreetmap.org/relation/390840 .  The
>>>>> "name" of both of these is currently set to a composite of the Inuktitut
>>>>> and the Anglo/French name.  Is this OK?
>>>>>
>>>>> Different OSM communities have adopted different standards - most have
>>>>> gone the "most widely used" form in the "name" tag (e.g. in places in 
>>>>> Wales
>>>>> will tend to have a "name" that matches name:cy in mostly Welsh-speaking
>>>>> areas and name:en in mostly English-speaking ones).  In some places (e.g.
>>>>> Londonderry/Derry, and around Brussels) a composite of multiple languages
>>>>> is in use; in still others (e.g. India) a "neutral" language is used
>>>>> (there, English).
>>>>>
>>>>> I did suggest on http://www.openstreetmap.org/changeset/41676348 that
>>>>> the person who changed the name raise it here; that didn't happen, so I'm
>>>>> mentioning it :)
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Andy Townsend
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> 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
>>>
>>>
>>
> ___
> 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] Ottawa has changed its Open Data licence.

[Denis Carriere]

That's great news!

For anyone interested in adding this data to Ottawa, please send me a
private message and I can explain our current workflow.

*~~*
*Denis Carriere*
*GIS Software & Systems Specialist*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Wed, Sep 14, 2016 at 5:15 PM, john whelan <jwhelan0...@gmail.com> wrote:

> http://ottawa.ca/en/mobile-apps-and-open-data/open-data-licence-version-20
>
> It should now be aligned with the Federal Government one so that should
> mean we can import the GTFS bus stop file.
>
> In Ottawa unlike some GTFS files the bus stops are very accurate, they
> carefully recalibrated each one as part of the system for announcing bus
> stops.
>
> More importantly I can retagged the paths in Ottawa that the city has
> tagged as bicycle=yes.
>
> Cheerio John
>
> ___
> 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] Prince Edward County - Sandbanks.

[Denis Carriere]

Should be fixed now and the OSM geocoding of "West Lake, Prince Edward
County
<http://www.openstreetmap.org/search?query=West%20Lake%2C%20Prince%20Edward%20#map=13/43.9355/-77.2918=H>"
works as well.

http://www.openstreetmap.org/relation/6526800

*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Wed, Aug 24, 2016 at 10:45 AM, Greg Franks <greg.fra...@gmail.com> wrote:

> Greetings.  Please forgive me if this is the wrong list.
> West Lake in Prince Edward Country (ON) is not identified as such, rather,
> it is labelled “Lake Ontario”.  I would rename it except that the body of
> water is connected to Lake Ontario at Wellington through the canal located
> there (the satellite imagery doesn’t quite match the lake boundary
> either).  I gather I need to split the polygon, but I am not familiar on
> doing so, and I don’t want to mess up all of Lake Ontario if I try.
> I did name “East Lake” (previously un-named).  However, the polygon
> includes the “Outlet River” which drains the East Lake into Lake Ontario,
> so it too needs splitting.
>
> Thanks.
>   ..greg
>
>
>
> ___
> 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] Prince Edward County - Sandbanks.

[Denis Carriere]

Hey Greg,

Dealing with complex relations can be a hard task, I've started cleaning up
the area and I'm going to add West Lake after I'm finished.

I will still keep the same geometry for Lake Ontario except add an
additional relation for West Lake.

Thanks for the OSM notification! :)

*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Wed, Aug 24, 2016 at 10:45 AM, Greg Franks <greg.fra...@gmail.com> wrote:

> Greetings.  Please forgive me if this is the wrong list.
> West Lake in Prince Edward Country (ON) is not identified as such, rather,
> it is labelled “Lake Ontario”.  I would rename it except that the body of
> water is connected to Lake Ontario at Wellington through the canal located
> there (the satellite imagery doesn’t quite match the lake boundary
> either).  I gather I need to split the polygon, but I am not familiar on
> doing so, and I don’t want to mess up all of Lake Ontario if I try.
> I did name “East Lake” (previously un-named).  However, the polygon
> includes the “Outlet River” which drains the East Lake into Lake Ontario,
> so it too needs splitting.
>
> Thanks.
>   ..greg
>
>
>
> ___
> 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] Improving navigation data in several cities in Canada

[Denis Carriere]

Great stuff Maning & the Mapbox team,

As for Ottawa, we have a good OSM community ready to help out for street
level photos.

We can host a few Mapillary/OpenStreetView events to promote the use of
OpenData in Canada.

Cheers,

*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Tue, Jul 12, 2016 at 10:00 AM, James <james2...@gmail.com> wrote:

> I use to collect imagery for Mapillary, especially around the Ottawa area,
> but now I'm collecting street imagery for OpenStreetView.com, which allows
> you to download your photos as you still own your photos. They are
> releasing more stuff(like public beta, josm plugin, etc) for the SOTM in
> Seatle.
>
> On Tue, Jul 12, 2016 at 9:46 AM, maning sambale <
> emmanuel.samb...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> This is Maning Sambale and I work with the Mapbox' Data team [0].  Our
>> team is working on improving carnavigation data in OpenStreetMap.  We
>> recently mapped turn-lanes [1] and turn-restrictions [2] in several
>> cities in the US.
>>
>> Right now, we want to extend this mapping to other cities around the
>> world. We mainly use Mapillary, hires imagery and other open data
>> sources to map.
>>
>> For Canada, we want to focus on several cities where Mapillary has
>> good coverage.  Initial cities are:Toronto, Vancouver, Ottawa,
>> Calgary, Montreal. Whenever, Mapillary is not available, we will not
>> map them.
>>
>> Before we begin, we want discuss first with the Canadian community.
>> We appreciate any idea, tool, reference data that can improve
>> navigation data in Canada.
>>
>> All  mapping projects will be posted in our mapping repo [3].
>>
>> [0] http://wiki.openstreetmap.org/wiki/Mapbox#Mapbox_Data_Team
>> [1] https://github.com/mapbox/mapping/issues/180
>> [2] https://github.com/mapbox/mapping/issues/187
>> [3] https://github.com/mapbox/mapping/
>> --
>>
>> cheers,
>> maning
>> --
>> "Freedom is still the most radical idea of all" -N.Branden
>> https://epsg4253.wordpress.com/
>> http://twitter.com/maningsambale
>> --
>>
>> ___
>> 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] Red Cross and Fort McMurray Fires

[Denis Carriere]

If anyone is interested in using this custom imagery in JOSM or iD, here is
the URL:

https://cdn.albertamapservices.ca/genesis_tokenauth/rest/services/Pleiades_RGB_Ft_McMurray_Fire_50cm/20160506/MapServer/tile/{zoom}/{y}/{x}

You can clearly see the damaged buildings:

https://pbs.twimg.com/media/CihrvYmU4AALP5N.jpg:large


*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Sun, May 15, 2016 at 1:40 PM, Dan Joseph <dan.b.jos...@gmail.com> wrote:

> Hi James,
>
> What was the source for the traced damage extent estimates? I was
> cross-referencing between the satellite imagery the Alberta government has
> made available for viewing at
> https://cdn.albertamapservices.ca/FortMcMurray/ and the extent polygons
> up on OSM tagged name="Fort McMurray Fire Damage Estimate" and there
> seemed to be differences. Also, I can't find the source now, but remember
> hearing that no schools were destroyed but am seeing several schools in the
> OSM damage extent polygons.
>
> Thanks and all the best,
> Dan
>
> On Fri, May 13, 2016 at 5:16 PM, James <james2...@gmail.com> wrote:
>
>> Hello everyone OsmCanada had a meeting tonight and have traced polygons
>> estimating the areas damaged and have named them "Fort McMurray Fire Damage
>> Estimate". They are tagged as brownfield as the buildings have been
>> destroyed or burnt down. The major areas affected are Thickwood, Beacon
>> Hill and Abasand. We thought this may help the red cross immensely.
>>
>> Big thank you to Rps333 for the help.
>>
>> On Fri, May 13, 2016 at 2:56 PM, Dan Joseph <dan.b.jos...@gmail.com>
>> wrote:
>>
>>> Hi John,
>>>
>>> Dale is the American Red Cross GIS Team Lead. I'm on his team and have
>>> been deployed to Canada to work in-person with the Canadian Red Cross. In
>>> terms of OSM-CA / Red Cross coordination, I can be considered the point of
>>> contact on the RC side until someone within Canadian Red Cross is ready and
>>> willing to take it on.
>>>
>>> All the best,
>>> Dan
>>>
>>> On Fri, May 13, 2016 at 2:44 PM, john whelan <jwhelan0...@gmail.com>
>>> wrote:
>>>
>>>> Have you talked to dale.ku...@redcross.org?
>>>>
>>>> A coordinated approach might be better.  OSM can use data obtained
>>>> through the Gov Canada open data portal and has done in the past as far as
>>>> I am aware.
>>>>
>>>> Thanks John
>>>>
>>>> On 13 May 2016 at 14:37, Dan Joseph <dan.b.jos...@gmail.com> wrote:
>>>>
>>>>> Hi James,
>>>>>
>>>>> It looks like some good progress is being made on the tasks.
>>>>>
>>>>> Tasks #22 and #23 are focused on mapping different features but it
>>>>> looks like #24 overlaps in focus. Perhaps that task should be archived
>>>>> until the other two are completed to avoid confusion among newcomers to 
>>>>> the
>>>>> site?
>>>>>
>>>>> Task #23 only provides minimal instructions (*Add address data via
>>>>> GeoBase. Add missing Roads and Street names.*). Would more people
>>>>> feel comfortable contributing if detailed instructions were included? It
>>>>> seemed the task is referring to the dataset described here:
>>>>> http://ftp2.cits.rncan.gc.ca/pub/geobase/official/nrn_rrn/doc/NRN.pdf
>>>>>   Is the Canada open government licence compatible with OSM?
>>>>>
>>>>> Thanks and all the best,
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On Fri, May 13, 2016 at 2:21 PM, James <james2...@gmail.com> wrote:
>>>>>
>>>>>> What exactly do you need of me? Prioritize areas to get mapped? We
>>>>>> have tasks for the buildings, addresses and streets(which I think have 
>>>>>> been
>>>>>> imported via CanVec) and a validation layer
>>>>>>
>>>>>> On Fri, May 13, 2016 at 2:14 PM, Dan Joseph <dan.b.jos...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm helping coordinate the Canadian Red Cross' use of GIS in their
>>>&

Re: [Talk-ca] Islands with coastlines not showing up in OSM

[Denis Carriere]

Thanks Adam,

Your answer & the osm wiki bring clarity to my question, I guess I'll just
have to be patient and wait until the coastline geometry gets processed on
the OSM servers.

Cheers,

*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com

On Wed, Feb 24, 2016 at 1:08 PM, Adam Martin <s.adam.mar...@gmail.com>
wrote:

> Hey Denis,
>
> Changes to the coastline takes time to pass through the tile rendering. If
> I recall correctly, the coastal tiles may take several weeks to update and
> require manual intervention. Looking at the Wiki, I see this (
> http://wiki.openstreetmap.org/wiki/Coastline): "*Coastline rendering in
> Standard tile layer
> <http://wiki.openstreetmap.org/wiki/Standard_tile_layer> may update later
> than other rendering changes. To avoid major disruptions of map rendering
> due to data errors the coastline is not automatically updated if there are
> larger changes in the geometry compared to the last time it was
> successfully processed. For example any addition or removal of a lake with
> coastline tag will require manual intervention.*"
>
> The same page also notes that "*At low zoom levels (used for z0-9), up to
> and including zoom level 9, Mapnik
> <http://wiki.openstreetmap.org/wiki/Mapnik> renders all the sea as a solid
> fill of blue, generated from the shapefile
> simplified-land-polygons-complete-3857.zip
> <http://data.openstreetmapdata.com/simplified-land-polygons-complete-3857.zip>,
> which has a relatively low resolution. At higher zoom levels the coast
> polygons used are generated from a larger shapefile
> (land-polygons-split-3857.zip
> <http://data.openstreetmapdata.com/land-polygons-split-3857.zip>) which are
> automatically generated almost daily from planet dumps + diffs (note: if
> you edit the coastline then you have to be patient for the result of the
> changes to render at the higher zoom levels).*" If your changes are very
> recent, it may not be showing up as the tiles have not been rendered. If
> they are older, check to make sure that the polygons are closed loops so
> that the renderer knows what to do with them.
>
> Adam
>
> On Wed, Feb 24, 2016 at 2:27 PM, Denis Carriere <carriere.de...@gmail.com>
> wrote:
>
>> Quick question for anyone on this mailing list.
>>
>> We are having issues displaying islands up in northern Canada, some
>> islands are showing up correctly and some do not.
>>
>> We seem to have all the tagging correct and the correct geometry
>> (validated with JOSM the coastline so it's not reversed).
>>
>> Any reason why it's not showing up properly in OSM? Is there a delay of
>> 24+ hours for any features that are related to the coastline?
>>
>> Here is one of many features that are not getting rendered:
>>
>> *Thomas Work Island, Nunavut (Not showing up)*
>> https://www.openstreetmap.org/way/398936588
>>
>> *OSM Tags*
>> name=Thomas Work Island
>> natural=coastline
>> place=island
>> source=NRCan-CanVec-10.0
>>
>>
>> Any ideas anyone?
>>
>>
>>
>> *~~*
>> *Denis Carriere*
>> *GIS Project Manager*
>>
>> *Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
>> *OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
>> GitHub: DenisCarriere <https://github.com/DenisCarriere>
>> Email: carriere.de...@gmail.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] Islands with coastlines not showing up in OSM

[Denis Carriere]

Quick question for anyone on this mailing list.

We are having issues displaying islands up in northern Canada, some islands
are showing up correctly and some do not.

We seem to have all the tagging correct and the correct geometry (validated
with JOSM the coastline so it's not reversed).

Any reason why it's not showing up properly in OSM? Is there a delay of 24+
hours for any features that are related to the coastline?

Here is one of many features that are not getting rendered:

*Thomas Work Island, Nunavut (Not showing up)*
https://www.openstreetmap.org/way/398936588

*OSM Tags*
name=Thomas Work Island
natural=coastline
place=island
source=NRCan-CanVec-10.0


Any ideas anyone?



*~~*
*Denis Carriere*
*GIS Project Manager*

*Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
*OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
GitHub: DenisCarriere <https://github.com/DenisCarriere>
Email: carriere.de...@gmail.com
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca