Re: [OSM-talk] Affordable 1 CM high precision GPS.

2024-05-05 Thread john whelan
It depends on the requirements.  I think mapping from Bing imagery is quite
reasonable and that isn't done to 1 cm accuracy.

However as you point out there are other solutions and I'm not advocating
one specific solution merely that it exists.  If there is a requirement
that needs high accuracy then this might work.

Perhaps it needs a wiki entry to list the advantages and disadvantages of
different approaches.  Certainly locally imagery is much better than GPS
near tall buildings.

Another issue is if you have two things in the map one that has been mapped
with high accuracy and one not there isn't really anyway to tell which is
the high accuracy one.

Cheerio John

On Sun, May 5, 2024, 14:30 Greg Troxel  wrote:

> John Whelan  writes:
>
> > Search Youtube for "Andreas Spiess ESP32 precision GPS receiver
> > (incl. RTK-GPS Tutorial)"  I deliberately haven't put a direct link
> > in.
> >
> > It needs packaging and documenting but I think this sort of
> > differential GPS could be very useful in accurate mapping.
>
> comments without watching :-)
>
>   RTK can be done for not a huge amount of money, less than a moderate
>   phone and a lot less than a new high-end phone.  The u-blox F9P is
>   about $200.  A decent antenna is another $100.  You need power and
>   cabling of course.  You then need to get RTK reference data and inject
>   it, and the F9P will compute RTK solutions.  I have an F9P; with good
>   reference data and a decent antenna, it works very well with clear sky
>   and ok in the forest, getting you fairly reliably within about a 1 m
>   vs 10 m non-RTK.
>
>   If you don't have a local RTK network reference you can run your own,
>   with double the hardware and some work to find the location of your
>   fixed antenna.
>
>   1 cm is a bogus claim; I have returned to the same piece of rebar
>   multiple times and the 30-sec averages cluster in a diameter of about
>   4 cm.  I do not know if there is systematic offset.  People tend to
>   believe the accuracy numbers they get out of the device and believing
>   them does not make sense.
>
>   One can also use rtklib with a receiver that outputs raw, without
>   needing an F9P.  This is less expensive and a lot harder.
>
>   This item it out of stock, and a fairly big markup, but
> - it works  (I have a report from a reliable nerd who has mapped
>   with it!)
> - it has a battery, a case, a display, a uSD for logging
> - it has an ESP32 to manage the F9P
> - sparkfun has been GREAT about actually working on the firmware
>   https://www.sparkfun.com/products/18442
>   https://github.com/sparkfun/SparkFun_RTK_Firmware/
>
>   cm accuracy is not really useful for mapping vs 5 cm or 10 cm, but
>   having 10 cm accuracy means you can just take the data as accurate.
>   trails that you thought you mapped well turn out not to be where the
>   map says.  mapping done with RTK is so much neater and cleaner.  It's
>   reasonable to map individual rocks and then the map looks like the
>   ground and lines up with the imagery.  If you haven't tried it you
>   don't know what you are missing.   I don't like to map trails with
>   regular GPS any more.
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Affordable 1 CM high precision GPS.

2024-05-05 Thread John Whelan
Search Youtube for "Andreas Spiess ESP32 precision GPS receiver (incl. 
RTK-GPS Tutorial)"  I deliberately haven't put a direct link in.


It needs packaging and documenting but I think this sort of differential 
GPS could be very useful in accurate mapping.


Cheerio John
--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Fwd: FW: [EXTERNAL] Re: ODbl concerns

2023-08-24 Thread john whelan
Apols to Allen, the message was too large with the old stuff on the end and
I forwarded it to the talk ca list by mistake.


-- Forwarded message -
From: john whelan 
Date: Thu, 24 Aug 2023 at 14:04
Subject: Re: FW: [EXTERNAL] Re: [OSM-talk] ODbl concerns
To: George Boulos (DTP) 
Cc: talk@openstreetmap.org , Robert C Potter (DTP) <
robert.pot...@roads.vic.gov.au>, Priya Maniam Chinakarapaya (DTP) <
priya.maniamchinakarap...@roads.vic.gov.au>


I was probably what you might call a glue person in the project. I was
interested in importing bus stops with the phone number to call for the
next bus in Ottawa to the map.

The new minister in charge of Treasury Board wanted to shake hands with
Open Data people.  So a group of a dozen of us got selected to attend.  The
most important people there were not the minister but his staff and when I
mentioned we couldn't use their open data because of the license they asked
me to repeat the statement and they listened.  Later they went on to talk
to other open data consumers. It took five years for their license to be
changed to something that looked like we could use.  In Canada we have a
long history of importing CANVEC data into the map.  The number of mappers
per square kilometer is much lower than say Germany.

In Ottawa we were very lucky in having a University lecturer who was into
Open Data and she was instrumental in many ways in forwarding the agenda.

I'd retired from Statistics Canada but knew their corporate culture quite
well.  It was about the time when the new license was approved, that they
decided to create a project about buildings.  The pilot would take place in
Ottawa seeing it was local and one of their staff had seen OpenStreetMap
and thought this was a great way that they could crowd source adding more
information about buildings.  They'd seen a building added with iD and
thought it would be simple.  This they would combine with other data and
sell to clients.

I drank my first cup of coffee of many with the project manager and
suggested it might be an idea to have a meeting to see if data could be
imported.  The new Federal government's Open Data licence looked as if it
matched OSM's licensing requirements so it looked sort of doable and
Metrolink had recently been adding addresses.  Metrolinx is a transit
organisation in Ontario and by adding addresses into OSM they hoped newly
occupied addresses could make use of route planning applications.

We had a meeting, City of Ottawa, myself, someone from Metrolinx who had
imported addresses from a Stats Canada source into OSM, they were there on
the phone, we had someone from HOT in Switzerland describing how HOT used
crowdsourcing to add data to OSM, the University lecturer who brought up
bilingualism, I had a Nexus running OSMAND in French displaying the Ottawa
street names in French and that probably sealed the deal as bilingualism is
mandatory and expensive in the Canadian civil service.  The lecturer
identified a dataset that the city of Ottawa owned and that became the data
set that would be later imported. The Stats Canada director who was at the
meeting said we'd turned the project into something quite different.

The City of Ottawa would need to change their license to align with the new
Federal one, that had to go to council but was eventually approved after a
delay of about a year.

The civil service and OSM are very, very different cultures.  The open data
would be imported by local mappers but only if they decided they would go
ahead.  We had two major targets in OSM, the locals and the heavies. Stats
had money so I suggested that the project manager attend SotM in europe.
Unfortunately at the last minute he was unable to attend but fortunately
his boss was and he met with a number of what I'd call the heavies of OSM.

The project manager and his assistant were dispatched to meet with the
local mappers and buy them coffee and flesh out the details.  We had a
group of enthusiastic mappers around, James was one of them.  They had a
half dozen physical meetings over coffee and agreed the import could go
ahead and that the local  OSM mappers would do it.

OSM has had a lot of substandard data imported into it over time so there
are now procedures to follow before importing the data.  Many mappers in
OSM, especially in Europe, don't exactly love data being imported and their
views are made known in the import process.  Getting approval to import is
not easy and dealing with the people involved was not easy either. You
can't just import, you have to have a process to deal with existing data in
the map. I'd have someone else do it.

The license was challenged. It would need to go to the Legal Working Group
for a benediction.  Their backlog was about three years.  However Mapbox
and others had heard about the project at the SotM and were interested.  I
understand one of their employees was a member of the LWG.  Somehow we got
the license approved for an import. 

Re: [OSM-talk] Announcing State of the Map 2024: Join us in Nairobi and online on 6-8 September 2024!

2023-08-22 Thread john whelan
I think there is a great deal to be said for holding SotM in different
locations.

The trouble is finding them.

Running a successful conference like this is quite a lot of work.

Locations that are used to holding conferences will have experienced teams
that exist.

Other locations will have to put together something from scratch which will
be more work so just coaxing people to do the work to put in a submission
is a major effort.

For Africa the ideal location would be one that is visa free for most
African countries.  Kenya may well be the African country that allows visa
free travel from the most African countries but it does require visas for
most African countries.

Then you get safety.  Is OpenStreetMap a terrorist target?  Unfortunately
the answer is yes.  If I wish to destabilise a country then I want to grab
any food aid and only supply my supporters.  So NGOs and OpenStreetMap
become targets.

Nairobi has been hit by terrorist attacks in the past.

I suspect there are safer African countries but you need to plan ahead and
what might be safe today might have it's government overthrown by a coup
tomorrow.

Then you get people voting with their feet.  SotM EU and SotM US may
attract more attendees and more interesting presenters.  How do you deal
with SotM becoming a side show?

Accessibility Oxford Street in London has roughly 1.5 million people within
a 45 minute journey by public transport.  I'm unsure what the numbers for
Nairobi are but the higher the number of locals the higher the number of
people who might attend.

Same sort of comment for longer distances.  What sort of destinations and
what frequency are available at the airport?  Any long distance trains
available?

One comment made to me by someone who attends a number of OpenStreetMap
conferences was at least they could take a bit of time looking at Ottawa.
Often they only saw the inside of the hotel and the conference building
which sometimes were the same building.  Apparently these days modern
hotels all look the same.

How do you ensure that this one would be any different?

My feeling is getting HOT and WHO involved might up the chances of success.

Cheerio John


On Tue, Aug 22, 2023, 19:28 o_andras  wrote:

> Hi fellow humans!
>
> (replying to the top email to avoid accidentally pointing fingers, lest
> anyone think I'm accusing them of anything; it's intended to be more of
> an introspection guide)
>
>
> I find it disheartening that "open and diverse" nowadays seems to mean
> "exclusive". The rules created to foster diversity and whatnot exclude
> too, turns out! So much for diversity...
>
> Of course, this is not news, I'm not the first to think it or even to
> say it (unfortunately I'm not the most expressive either; let's hope I
> can get the message across). Is it taboo to talk about it? I've seen
> others expressing this sentiment and being shunned for it.
>
> Can't the (possibly) affected part of the community understand this? A
> SotM hosted in a "western" country (strong emphasis on the quotes!),
> maybe it's welcomming to the global community -- we the "westerners" are
> so much better after all (that was sarcasm, if you couldn't tell...)
> But is it accessible to the global community?
>
> And didn't you, a "westerner", get the chance of attending several SotMs
> already? And are you part of the OSM community to "westernize" the
> "non-westerners"? Never thought of going to other places to learn
> different ways of life, etc?
>
> Being "good" or "bad" is not so clear-cut, either. There are some better
> things and some worse things. Being worse at something doesn't make it
> worse at everything.
>
> Certainly, not everyone in a given country is the same. You should know
> -- can you positively say there's no discrimination in your own country,
> just because you yourself don't discriminate in your own country? I wish
> you and I both could...
>
>
> OSM or the SotM isn't your own toy, that you can lend for others to play
> with. It's more of a leisure=playground; access=yes. Let everyone have
> their turn. If you don't want to go down the slide today (no matter the
> reason), go to the swing. The slide will be there for you another day.
>
>
> PS: please avoid replying with examples of extremism. From my pov it's
> not relevant to the SotM discussion.
>
> Best regards,
> o_andras
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Mapping in war zones

2023-08-18 Thread John Whelan

I'm looking for thoughts on this.

Specifically Mali at the moment.  Are there any NGOs still operating or 
am I just defining targets for the Wagner group etc?


Ideally any input from local Mali mappers would be valued together with 
thoughts for a more general case.


Many Thanks

John
--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Announcing State of the Map 2024: Join us in Nairobi and online on 6-8 September 2024!

2023-08-16 Thread John Whelan
Whoever said life was easy.  My understanding is Kenya requires visas 
for many African countries so perhaps ease of obtaining visas etc should 
go on the list.


I sympathise with the idea of holding one in Africa or elsewhere I just 
naturally look for any problems that might arise.


Running a successful conference takes expertise, and attention to 
details, experience helps so perhaps some central organisation might 
help or give guidance.


HOT held a conference in Ottawa a year or two ago.  It was held jointly 
with Statistics Canada, but I seem to recall it was held in term time. 
There was an open data conference held here some years ago that had a 
lot of OpenStreetMap clients and mappers present, including HOT I think 
that one was run by External Affairs.  A number of attendees stayed at 
Ottawa University.


I think we need to focus on what we'd like to see.  For example Ottawa 
OpenStreetMap group has probably done the most comprehensive imports of 
Open Data into OSM of any city.  Is there a tale to tell to other cities 
on how to make their data available and what are the advantages? Yes I 
understand many mappers feel that real mapping is done with physical 
mappers but sometimes getting a complete set of bus stops with the code 
to call for bus times has value.


Has anyone done any financial analysis of Open Data and can we improve 
the map in Africa by using it and thus outcomes.


Ireland might work well, Dublin has good air connections.

Is there a danger that SotM US or SotM EU might become larger than SotM 
so it becomes less relevant?


I might suggest that alternate years somewhere more exotic is chosen 
than the EU.


Cheerio John

Frederik Ramm wrote on 8/16/2023 3:43 PM:

Hi,

On 8/16/23 20:01, John Whelan wrote:
If it was in the EU or the USA a higher proportion of members would 
not need a passport or visa.


... but almost all visitors from Africa would, and more importantly, 
many would have a very hard time obtaining it. Whereas the average 
"westerner" wanting to go to Nairobi simply fills out an online form 
and gets their visa within a couple of days.


For future SotMs I might suggest starting with accommodation, many 
universities have halls of residence available during the summer months.


These are good ideas but remember that SotM is not centrally 
organised. The SotM team puts out a call for location, and local 
groups can then apply. An application from a local group who have 
thought about these things, and who say "we've talked to our local 
university and there's affordable accommodation there" will certainly 
be looked upon favourably, but that's about all - the OSMF SotM team 
will not scout the world for locations with affordable accommodation, 
simple visa rules and cheap travel, all they can do is evaluate the 
bids that have been submitted.


Ottawa for example has halls with double beds and ensuites plus there 
are lecture halls etc available.  Meal plans can be purchased which 
means that you're eating in the cafeterias true but many 
conversations at SotM will take place outside the conference rooms 
and over a meal is a useful place to talk.


I would love to go to a SotM in Canada, however there has only ever 
been one bid from a Canadian team and that was withdrawn over the 
announcement of SotM US being at the UN in New York that year! If you 
can get a few Canadians to submit a bid for a SotM in one of the 
coming years, I'm sure that would be very attractive.


The EU might be easier than the UK since britexit the UK is no longer 
a free travel zone for EU citizens and the EU has trains which means 
a lower average carbon footprint per attendee.


The OSMF has been criticized for having run the last three in-person 
SotM conferences in Europe (two in Italy, one in Germany) so you can't 
blame them for looking elsewhere! Which doesn't rule out future 
European SotMs - after all, that's the continent where OSM was 
invented - but it's certainly good to go elsewhere once in a while, 
even if that is outside of the comfort zone for the average European 
or American traveller.


Bye
Frederik



--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Announcing State of the Map 2024: Join us in Nairobi and online on 6-8 September 2024!

2023-08-16 Thread John Whelan


Andrew Hain: "I would like to congratulate the organising team in 
Nairobi and the SotM Working Group for doing this. Giving the worldwide 
community a broader understanding of the challenges of mapping Africa 
and using maps there is positive step for OSM’s inclusiveness as a truly 
worldwide map. "


I think we need to balance things out. There is a need to expose Africa 
to different ideas but being pragmatic this won't be done in a day.


I think we also ought to recognise that travel within Africa is not 
easy.  Many African countries do not have direct flights to Nairobi and 
even when they do exist they aren't cheap.


"inclusiveness" I think we need to recognise there are many barriers 
here.  First the cost of flights from say Cairo to Nairobi is close to 
the cost of London to New York.  Europe to Nairobi in general is more 
expensive than a transatlantic flight.  Thinking of where our members 
live do they need a passport or visa?  If it was in the EU or the USA a 
higher proportion of members would not need a passport or visa.  I seem 
to recall yellow fever vaccine certificate is required and Ebola 
outbreaks have occurred in neighbouring countries.


The Canadian government's advice for travel to Kenya is in the link.

Travel advice and advisories for Kenya 



Basically there is a credible risk of terrorist attacks in Nairobi, and 
there have been some there already according to the web site.  The crime 
rate is high so basically you're living in a hotel and the conference 
area.  Sightseeing is not recommended.


In summation I think what we'll see is a SotM dominated by locals from 
Kenya, attendees from commercial companies or others on expenses, and a 
few more wealthy mappers than we would in other locations.  Whether this 
is good or bad I make no comment.


I note that the recent World/Scout/Jamboree got hit by high 
temperatures, with global warming should the average expected 
temperature be taken into account?


For future SotMs I might suggest starting with accommodation, many 
universities have halls of residence available during the summer 
months.   Ottawa for example has halls with double beds and ensuites 
plus there are lecture halls etc available.  Meal plans can be purchased 
which means that you're eating in the cafeterias true but many 
conversations at SotM will take place outside the conference rooms and 
over a meal is a useful place to talk.


I'd suggest running it over a weekend with the weekend free.  That way 
those on expenses can grab a bit of sightseeing and the airfares 
typically are cheaper with a Saturday night stay.  Plus you can run a 
few more informal activities over the weekend.


The EU might be easier than the UK since britexit the UK is no longer a 
free travel zone for EU citizens and the EU has trains which means a 
lower average carbon footprint per attendee.


Note to Amanda realistically with the high crime rate and 
"Women’s safety: Women travelling alone may be subject to some forms of 
harassment and verbal abuse. Attacks involving sexual assault have 
occurred."  The LBGTQ side of things might be the least of your problems.


Have fun but do your risk analysis before attending and know what to expect.

Cheerio John



Amanda McCann wrote on 8/16/2023 12:00 PM:

I'm an out, queer trans woman. I presume this event won't be safe for people 
like me?

It's illegal to be gay in Nairobi, and parliamentarians are proposing even 
stricter, oppressive laws¹. Trans people are often lumped into the same group. 
The last SotM CoC² said: “[we are] dedicated to providing a harassment-free 
conference experience for everyone, regardless of … gender identity and 
expression, sexual orientation, …. We do not tolerate harassment of conference 
participants in any form”. This CoC wouldn't be possible in 2024, right?

I presume the advice from the SotM WG is that this event cannot for LGBTQ 
people, right?

Oh, doesn't this go against the OSMF/SotMWG's safety policy?³

¹ 
https://www.reuters.com/world/africa/kenya-could-follow-uganda-east-african-nations-wage-war-lgbt-rights-2023-06-22/
https://www.bbc.com/news/world-africa-66079603
² https://2022.stateofthemap.org/codeofconduct/
³ 
https://wiki.osmfoundation.org/wiki/StateoftheMap_Organizing_Committee/StateoftheMap_safety_policy

On Mon, 14 Aug 2023 19:56 +02:00, Federica Gaspari  
wrote:

Dear all,

Get ready to meet and connect with old and new mappy friends from the
global OpenStreetMap community again!

The State of the Map Organising Committee is thrilled to officially
announce that the global conference of the OpenStreetMap community,
State of the Map (SotM), will be making its way to Nairobi, Kenya from
September 6th-8th 2024! This landmark event will bring together
passionate mappers, data enthusiasts, technologists, and community
members from all corners of the globe to celebrate the spirit of
collaboration and open mapping.

Following the good feedback 

Re: [OSM-talk] Adding automated trees to OSM

2023-08-08 Thread john whelan
So to sum up these are trees that you have not personally inspected and
added to the map but you are relying on a third party for the information
and you can't be sure exactly where it is from nor how accurate it is?  Nor
do you have any idea of the license on the data.

Based on my interpretation of your reply, please don't do this.  If you
must press ahead then at least follow the automated edit rules and go
through the formal import process including checking the license is
compatible with OSM.  Many open data licences are not.

Cheerio John

On Tue, Aug 8, 2023, 14:25 Harsha Somaya  wrote:

> Thanks for the link. Answering your question below:
>
> 1) what is the source of tree data--- from an open source app that allows
> users to capture images of trees
> 2) can you give samples of tree data that would be added?-- an example
> would be trees that are around my residential house, healthy trees
> 3) where it would be added-- for now, mainly the US area
> 4) how you will prevent duplication with existing trees-- code makes sure
> that no two trees at the same GPS can be added
> 5) which tags will be used-- species, genus, maybe height, image of tree,
> maybe wikipedia tree about species, tree type (broadleaf versus not)
> 6) have you verified quality of data you want to add-- In terms of verify,
> we make sure it is a healthy tree that has not already been added
>
>
> On Tue, Aug 8, 2023 at 2:12 PM Mateusz Konieczny via talk <
> talk@openstreetmap.org> wrote:
>
>> 1) what is the source of tree data
>> 2) can you give samples of tree data that would be added?
>> 3) where it would be added
>> 4) how you will prevent duplication with existing trees
>> 5) which tags will be used
>> 6) have you verified quality of data you want to add
>>
>> Also, I want to echo comments from
>>
>> https://community.openstreetmap.org/t/osm-tree-automation-worldwide/102197/2
>>
>>
>> Aug 8, 2023, 20:06 by hsomaya2...@gmail.com:
>>
>> Hello! Hope everything is well. I am trying to add trees to OSM in an
>> automated way via python. Of course, these are real trees that I do not
>> want to add manually. I am planning to run the script every 30 minutes to
>> process about 100 trees at a time, creating 7 changests for every run/30
>> min interval. Hence, every 30 minutes 7 changesets will be created, each
>> having about 14 trees/nodes. These trees will be relatively close around a
>> central GPS point. The comment would be similar to "Adding 14 trees all
>> clustered around X GPS coordinate." Does the community have any concern or
>> suggestions for this? Thank you, and I look forward to hearing from you all
>> soon.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> --
> With gratitude,
> Harsha
>
>
> [image: Colby] 
>
> Harsha Somaya
>
> (She/her)
>
>
>
> 
> [image: LinkedIn] 
>
> ___
> 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: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

2023-05-19 Thread John Whelan

shop=consignment

Locally it means a shop that sells things such as high end used clothes on 
consignment.  ie the owner of the goods only get paid when the items are sold.

Cheerio John



Philip Barnes wrote on 5/19/2023 12:25 PM:

On Wed, 2023-05-17 at 20:48 +0200, Mateusz Konieczny via talk wrote:

For start there is a long list of shop values which meaning I do not
understand
(for example, from start of list of exactly such values:
shop=grossery, shop=towing, shop=showroom, shop=salon, shop=garage,
shop=pond, shop=consignment...)


Maybe here I have the advantage of being a native speaker but these
mostly look fairly intuitive to me. Also looking at the names often
helps.

shop=grossery
First glance it looks like a typo of grocery.
There is one in the UK which is a small co-op. So that one should be
shop=convenience. I do not know about the usage in Cameroon but asking
local mappers is preferable to simply changing the tag to =yes. They
could well be foodshops/grocers>

shop=towing
First thought is 'depends on the flavour (or flavor) of English.

Usage is mostly in North American and it looks like breakdown, tow your
vehicle. Names tend to confirm this.

shop=showroom
Where stuff is displayed for sale to be installed seems to be the
thing.
A bit like the Gas Showrooms of my childhood. These were places where
gas appliances were displayed, you paid for them and they were then
fitted by their staff.


shop=salon
Salon is a common name used for a hairdressers shop, so most likely a
mistagging of shop=hairdresser or beauty.
The names of places with those tags tends to confirm my suspicions.

shop=garage
Garage has a few car related meanings. A place where you take your car
to be repaired, fill it with fuel or its a building where you keep your
car.

Tags of the places using this suggest a mix of car stuff. Mostly car
repair. For example https://www.openstreetmap.org/way/153706791 has a
note MOT operator, so car testing/repair
and https://www.openstreetmap.org/way/509612586 Chesterfield Concrete
Garages will obviously sell you a concrete pre-fabricated garage to put
in your garden.

shop=pond
This one seems obvious. Immediately thought of a shop selling pond
supplies, pumps, liners, plants, fish for your garden pond.
More commonly tag usage is shop=aquatics.

The main thing if you don't understand a tag

shop=consignment
The word consignment suggests a courier but appears to be a thing in
the US and Canada. Quite a few, and it seems to be what they describe
themselves as.
I am prepared to accept that this is outside my life experience and if
I need to understand it I will ask the local community or a mapper who
has added them. Actually there a two within a few minutes walk of my
cousins in her local high street, so I could ask her.

But changing these to shop=yes helps nobody. As I mentioned shop=pond
would probably have been my first thought if I wanted a pump and liner
for my garden pond.

Phil (trigpoint)

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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

2023-05-03 Thread John Whelan



Courtney wrote on 5/3/2023 4:00 PM:
Compare a statement like this:

 "I know you may be relatively new here, so to help you be successful, 
here are some ideas for how to structure for your project"


to a statement like this:

 "I am disappointed to yet again see someone doing this wrong and 
ignoring the requests of the community"



There is a difference in the level of language proficiency needed to use 
the first sentence so you're asking a great deal of people using a 
second language to use that level of proficiency.
This might be appropriate for easing people into a new situation  but I 
think you also have to take into account that technical people and there 
are many here usually are more direct , blunt if you like.


How would you rephrase Fredrick's post by the way?  I may have missed 
your answer.


Can you clarify who "your team" in this context is? You were introduced 
in Marjan's initial post as "OSMF Communication Working Group Member" 
and were the only of four names without a TomTom affiliation. You are 
posting this neither from an OSMF nor from a TomTom address but from a 
gmail one.


Is "your team" a corporate TomTom endeavour? Is it the OSMF 
Communications working group? Or...?


Unclear affiliations are a problem, as I pointed out in this thread a 
few days ago. Has everything I said been filed away under "pushback" and 
ignored?


Many Thanks

Cheerio John
--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

2023-05-03 Thread John Whelan

A very accurate summation in my opinion.

Thank you

John

Imre Samu wrote on 5/3/2023 1:03 PM:
Courtney > ezt írta (időpont: 2023. ápr. 
30., V, 19:06):


This conversation has opened up important new questions.  Why is
the main "Talk" channel the only one that is producing pushback?
Why is it the only one that is producing such a negative tone? 



Hi Courtney,

I think it's important to mention the problems arising from 
*intercultural differences*
in your SOTM US - OSM Communication Presentation, as the OSM community 
currently struggles with misunderstandings between different cultural 
groups.


Although the "OSM Diversity Statement" has been accepted, its 
practical implementation isn't fully successful yet. *Ethnocentric 
attitudes* need to be addressed, and we must be more open to other 
cultures. However, this is easier said than done.


IMHO:
Most conflicts within the OSM community and on the OSM-Talk mailing 
list are due to *intercultural differences,* and there's no current 
mediation or conflict resolution in place. It might be helpful to have 
"intercultural mediators" who can bridge the gap between cultures and 
help understand other cultural groups.


I mainly notice the clash between American and EU/German cultures, but 
other cultural conflicts are likely as well.


Probably the EU/German OSM community needs to learn how to wrap their 
raw, honest messages in a sugar coating, making it more palatable for 
those with an American cultural background. Conversely, the American 
community should strive to be less sensitive towards differing norms 
from other cultural communities, embracing the deep-level diversity 
that comes with global collaboration. ( [1], [2]  )


Unfortunately, the current OSM Etiquette Guidelines [ 
https://wiki.openstreetmap.org/wiki/Etiquette/Etiquette_Guidelines ]  
do not provide much assistance in understanding and resolving 
intercultural issues. To improve the guidelines, it would be 
beneficial to incorporate information on intercultural communication 
and provide resources to help community members navigate these 
challenges effectively. This would promote a more inclusive and 
harmonious environment within the OSM community.


In addition to this, new OSM community members should be prepared for 
the potential culture shock they may encounter, especially those who 
come from a top-down corporate environment. It's important to remember 
that OpenStreetMap is characterized by a bazaar-style, bottom-up 
communication approach, which may be an adjustment for some. Embracing 
this unique aspect of the community will help newcomers adapt and 
thrive in the OSM environment.


In fact, this is a big topic, and when I consider the OSM community 
problems from the past few years through the viewpoint of cultural 
differences, it gives me a good understanding of the reasons.


Generally, the OSM Talks mailing list is characterized by *"deep-level 
diversity," and as a result, more productive conflicts are expected 
than usual,* which is normal based on some diversity research [3]. 
This means that diverse perspectives and experiences can lead to more 
engaging discussions and ultimately result in innovative solutions and 
ideas for the community.


I would be curious about others' opinions as well. To what extent can 
cultural diversity be a problem? And how can we alleviate conflicts 
and amplify the advantages arising from cultural differences?




contexts:
[1]
/""According to Hofstede, a typical conversation in a German cultural 
context is characterized by a large degree of honesty, even if it hurts./
/Consequently, Germans are perceived to be among the most direct 
communicators in the world (Yin, 2002).
Presumably, the strategy “be honest even if it hurts” offers the other 
party the opportunity to understand and learn from possible mistakes.
In a qualitative study, Yin (2002) explored the concept of  German 
wahrheit (truth), in terms of a German standard for communicating in 
public.
She describes wahrheit as expressions of an individual’s personal 
opinions, using the first pronoun: “The wahrheit can be displayed in a 
manner that implicitly or explicitly indicates the rightness of one’s 
own opinion. In public talk, as one German informant put it, ‘Telling 
the wahrheit hurts a little bit, but it’s okay’” (Yin, 2002, p. 249).  
As a result, frank and forthright discussion with open disagreement 
for the sake of the discussion is preferred" Indeed, not directly 
telling the wahrheit was perceived as hiding personal opinions or 
lying by the German participants in Yin’s (2002) study.

...
Additionally, Yin’s (2002) findings suggest that German and 
U.S.-American meetings might differ in terms of the frequency of 
counteractive meeting behaviors. Her finding that Germans were more 
outspoken, cared particularly for telling the honest truth (even if it 
hurts), and expected others to do so as well, could imply a 

Re: [OSM-talk] Survey about OSM communication behaviors

2023-04-30 Thread john whelan
*I object only to the tone of some of the comments, and to assumptions that
are made about our motivation, decision process re: our approach, and
quality of our skills. I'm not alone in objecting to problems of tone more
broadly, and so I feel comfortable insisting on a higher quality discourse
here on behalf of myself and the many others who share this concern. I
think that good forum etiquette requires that people assume the best and
ask clarifying questions. As well, there are several very commonly used
phrases and rhetorical devices that can be deployed to make 'advice' feel
like advice instead of condemnation or scorn. *

Tone is difficult it is cultural.  For example think about gun
control.  I think
Allen Mustard is one of the very few people on the list who comes anywhere
near a polite tone that is understandable by many.  The American ideas and
UK ideas are very different.  1066 might not mean much to many people but
it has a great deal of meaning to few.

Then you get to big city dwellers and small city dwellers.  Small
city dwellers tend to have longer greetings than big city dwellers.  In
some places it is perfectly acceptable to raise an eyebrow as a form of
greeting although it might seem odd to you.  Surveys on OSM on talk are
interesting, it seems everyone and his dog wants to run a survey about OSM
mappers and why they do it.  There is a concept called respondent burden or
"is this yet another survey?" which might explain the lack of enthusiasm
you may encounter.

There are many people here who don't have English as a first language.
Although some such as Americans think they do.  I live in Canada which is
to a large extent bilingual.  In the office we had a francophone who was
rated exempt for English oral.  I had a coworker who came from the UK not
many miles away from where I was born and one day we spoke using local
slang and she understood about one word in ten. We could even speak using
words she understood but lacked the references for their meaning.

OSM is a place where the importance is placed on the map.  Social skills
are not a job requirement and to be honest some of the most productive or
should I say obsessive mappers can be very black and white but they really
do great mapping and I think that is important.

Finally face to face is usually best for communication which is why I have
been known to persuade someone to go to Europe in person to a state of the
map when I wanted to pull something together but mailing lists serve a
purpose.

Cheerio John


On Sun, Apr 30, 2023, 17:26 Courtney  wrote:

> Hi, all,
>
> Here, thanks to the generosity of some folks on the OWG and OSMF who
> donated their time to us so that we could have access to an open source
> tool of this quality, is a LimeSurvey version.
>
> https://osmf.limequery.org/751285?lang=en
>
> Please do fill it out and share it widely within the mailing lists. Please
> do not share it in other channels (Twitter, Mastodon,
> community.openstreetmap.org, etc.) as I will be posting unique versions
> in those channels.
>
> Once again, it is OBVIOUSLY our first choice to offer an open source
> survey; we didn't because we initially couldn't. Now, we are able to, and
> I'm glad of it.  I share the concerns that many of you expressed and fully
> understand and value the complexity and importance of the commitment to
> open source software and data.  I also have a good understanding of the
> nuances and complexity of this conversation. Indeed, I celebrate them.
>
> I object only to the tone of some of the comments, and to assumptions that
> are made about our motivation, decision process re: our approach, and
> quality of our skills. I'm not alone in objecting to problems of tone more
> broadly, and so I feel comfortable insisting on a higher quality discourse
> here on behalf of myself and the many others who share this concern. I
> think that good forum etiquette requires that people assume the best and
> ask clarifying questions. As well, there are several very commonly used
> phrases and rhetorical devices that can be deployed to make 'advice' feel
> like advice instead of condemnation or scorn.
>
> C
>
>
>
>
> On Sun, Apr 30, 2023 at 3:56 PM Greg Troxel  wrote:
>
>> Courtney  writes:
>>
>> > Can I ask--what is the fundamental objection to us trying to learn a bit
>> > more about OSM communication habits?
>>
>> I think you are misinterpreting.  I detected no objection to trying to
>> learn.  I only see objection to proprietary tools and pushing users to
>> surveillance.
>>
>
>
> --
>
> --Courtney Cook Williamson
> survivalbybook.substack.com
> ___
> 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: [OSM-talk] Survey about OSM communication behaviors

2023-04-30 Thread john whelan
My background was working with surveys and my comments simply came from
that background and the steps taken to obtain accurate results.  Nothing
else.

Typically a university run survey isn't done to high standards.

Your comment on questions from talk I think relates to the users.
OpenStreetMap roots are in open data and a desire to avoid proprietary
systems.  The old fogies, if you will, tend to use mailing lists, they do a
lot of editting and background work to make it run smoothly
disproportionately so.  Often they don't use the flavour of the month
online forum.

So if you ask in an online forum are on line forums great you'll get a
positive answer.  Those who don't think they are great won't use them.

If you ask in the talk mailing list you get a different set of respondents.

As I said before the selection of the sample is critical.  There is a story
told of an interviewer who surveyed passengers at a railway station about
gambling.  100% were in favour.  It was only later it was spotted she'd
interviewed people who were there to catch a special train to a race course.

So what exactly are you trying to measure?  Are you weighting the replies
against the number of edits the person has made?  Does a HOT mapper who has
made three edits count.  Remember that they will almost certainly have been
recruited through social media.

Then you get people who map quite happily by themselves or in a very small
group of two communicating one on one via email.  Not everyone feels the
need to group hug in an online forum.  The mapper I'm thinking of is exHOT
and prefers to quietly map parts of Africa that are basically unmapped.  We
do work together and communicate via email to decide which bit to map
next.  Remember HOT is very much working together and for some mappers this
doesn't work well.

So are you interested in a sample of OpenStreetMap mappers or a sample of
online forum mappers who are happy with Google forms as your sample?

There is a difference and as long as you don't say our survey says everyone
in OSM thinks this about online forums I'm happy and content.

Cheerio John

On Sun, Apr 30, 2023, 13:06 Courtney  wrote:

>
> We do indeed have people with non technical backgrounds working on the
> survey, including a multilingual person with an advanced degree in language
> and technology, and a person with an advanced degree in English language.
> We have two very experienced data analysts working on it, as well.
>
> We did not run a trial survey against a random sample because, as I said
> in my previous post, this survey is an ancillary part of a larger,
> long-term study that relies on publically available data from OSM
> communication channels. We are also quite capable of framing our findings
> within the context of how the survey was distributed, with appropriate
> reference to everything from survey bias, to the difficulties of conducting
> a free survey across a global community, to the short amount of time that
> we have to do the survey. No one is claiming that we will be able to
> deliver the one true, definitive quantitative analysis of OSM communication
> behaviors to rule them all. We are attempting to uncover some
> directional behaviors, and see if we can foster
> a better conversation within the community.
>
> This conversation has opened up important new questions.  Why is the main
> "Talk" channel the only one that is producing pushback? Why is it the only
> one that is producing such a negative tone? How widely is the principle of
> using only open source software adopted across the community? We already
> had a question to this effect within the survey, but we will now be able to
> learn more by adding the limesurvey. None of this is going to be
> definitive. All of it is going to be interesting and help raise new
> questions that hopefully can be studied.
>
> Can I ask--what is the fundamental objection to us trying to learn a bit
> more about OSM communication habits? I understand the impulse to give
> advice--this is welcome even when the advice is predicated on the idea that
> we lack any kind of insight or experience--there is always more to learn.
> But, I don't understand the degree of ire and frankly, incredulity that is
> being levied here.  Should we wait until there is a university study that
> is fully funded and staffed, and with a perfect approach, with a year's
> worth of pre-testing, to ask these questions? Is that the standard here?
> Wait for perfection or do nothing?  Is that how OSM itself was built? I
> don't understand the tone or the defensiveness of these comments. If the
> goal is to advance the OSM project, is it better to gate keep all inquiries
> to a suffocating degree? Or to try to learn and grow?
>
> On Sun, Apr 30, 2023 at 11:45 AM John Whelan 
> wrote:
>
>> Just a comment on Fredrick's input.  S

Re: [OSM-talk] Survey about OSM communication behaviors

2023-04-30 Thread John Whelan
Just a comment on Fredrick's input. Selecting the sample is one of the 
most difficult parts of a survey to get right.  The self selection part 
of this survey makes it open to bias, as Frederick has commented this is 
compounded by the platform. I'm not making a comment about if the 
platform is appropriate or not just that if it affects your response 
then it begins to cast doubt on your results.


The second is knowing enough about your target audience so they will 
understand your questions.  Perhaps have someone non technical with an 
English Language background, a librarian, for example check it for 
jargon.   One technique is to run a trial survey against a true random 
sample.  I don't think this was done here.


If they don't understand what you're asking then you aren't going to get 
a reliable answers and to be honest I didn't.


I'm not sure if this particular survey is trying to justify a particular 
stance or get accurate information.


Cheerio John

Frederik Ramm wrote on 4/30/2023 11:18 AM:

Hi,

On 4/28/23 15:57, Marc_marc wrote:

I am impressed (and disappointed) that those who do these surveys
have still not learned that part of the active opendata community
does not wish to ally a closeddata based enterprise (nominally:
no use of google forms for some of us).


Agree. It's one thing for an OSMF working group to use a closed 
source/siloed product internally, but quite another to attempt to 
engage with the community via such a product.


I am not surprised when a commercial company like Tom Tom does that 
without a second thought, but I would expect more from an OSMF working 
group.


Please find a way for non-Google users to participate in this survey, 
or your results will be biased to the point of un-suitability because 
they will lack responses from people who'd rather not engage with 
Google, i.e. the whole "communication behaviours" of this group of 
people would not be represented.


Bye
Frederik



--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Talk-GB Digest, Vol 197, Issue 27

2023-04-02 Thread john whelan
I suspect the National Trust of which I happen to be a member is much more
centralised and top down than OpenStreetMap which tends to be more bottom
up.  It is a different culture and the OSM side has evolved over time.

I'd ask you to be nice to us and work with us where possible.  The OSM
volunteers can be very useful in filling in details on the maps.  The more
experienced ones are very good.  New ones involved in a mapathon depend on
who is running it.

Rose worked at one of the properties for a while and whilst she spoke four
languages and could get by in a few more she was surprised by the number of
different languages spoken by the visitors.  OSMAND is based on OSM and
currently is available in 45 different languages.  The data is the normal
internal OSM database and both the interface and content can be displayed
in the language of choice.  Names can be tagged in other languages,  for
example name:fr=Londres

This has been particularly useful locally when dealing with official
languages and I seem to recall the National Trust owns a few in Wales.

I suspect there can be a lot of mutual benefit if the two organisations can
work together.

Cheerio John

On Sun, Apr 2, 2023, 18:24 Ragone, Olivia via talk 
wrote:

> Thank you for providing feedback on some of the edits made by National
> Trust staff as part of our organised editing activity, on the
> representation of paths. We’d like to apologise that it has taken some time
> to provide a response.  We are always open to constructive feedback that
> helps us to add value to OSM for the benefit of all.
>
>
>
> The aim of the National Trust’s organised editing activity is to capture
> and accurately tag the access rights of all paths on or near National Trust
> managed land. In doing so, we hope to use it as the basis for enhancing
> access and the management of paths, to improve visitor experience.
>
>
>
> We are trying to be consistent in how ways are tagged / represented in
> OpenStreetMap. A standard schema and internally developed guidance are
> being utilised to help map commonly occurring scenarios. This schema can be
> found on the OSM Wiki page (link). We currently have 5 staff members
> conducting remote mapping sessions with local rangers to gain their
> on-the-ground insight. We believe that working with the on-the-ground staff
> provides our best available source of local knowledge, but we acknowledge
> there may be situations where there are differing opinions on path
> representation. The Trust invite feedback from OSM mappers, but it may take
> some time to review each situation.
>
>
>
> In the time available, we are focusing on the existence of the path (ie.
> location and connectivity) and the legal right (ie. access tags). In the
> future, we hope to look at other attributes to represent the
> characteristics of the path. Following the initial data capture, we plan to
> hand over OSM updates to the ranger teams; we are currently refining the
> guidance material to support this. Feedback from the OSM community to help
> ensure we are providing appropriate guidance is welcome.
>
>
>
> We tend to use a standard changeset comment as it would be very difficult
> to capture details of every change. However, since receiving feedback on
> the Talk-GB mailing list, we have amended our standard comment to be more
> representative of the type of changes that have been made on individual
> properties. As part of the process, we have a monitoring tool that looks at
> the weekly changes to paths in OSM on land managed by the National Trust.
> This could be made publicly available as an Esri Open Data WMS if it would
> provide further transparency. We accept in the time that we have,
> occasional errors will be made. After our first round of data capture, we
> have allocated time to analyse and assure the quality of changes by our
> team.
>
>
>
> Overall, we expect that the changes will improve the representation of
> paths on OSM, but we are very keen to improve our process by utilising the
> wealth of knowledge and experience in the OSM community.
>
>
>
> National Trust Paths & Trails Team.
>
>
>
>
>
> *GIS Data Officer (Paths) *
>
> *National Trust*
>
> *Email:* olivia.rag...@nationaltrust.org.uk
>
> nationaltrust.org.uk
> 
>
>
>
>
>
>
>
>
> -- The National Trust is a registered charity no. 205846. Our registered
> office is Heelis, Kemble Drive, Swindon, Wiltshire SN2 2NA. The views
> expressed in this email are personal and may not necessarily reflect those
> of the National Trust unless explicitly stated otherwise. This email and
> any files transmitted 

Re: [OSM-talk] Automated Edit - Bus stops status link & Bus lines timetable link (Tenerife)

2023-03-26 Thread john whelan
I'm lost here.

We have something in the map and we can associate a website with it.

Why would we need to have permission from the local mappers to do this?

I note locally our bus stops have a reference that does much the same thing
but I don't recall having to canvas local mappers about it.

On a personal note anything that makes catching a bus easier has my vote.

Cheerio John



On Sun, Mar 26, 2023, 12:08 Marc_marc  wrote:

>   On Fri, 2023-03-24 at 20:33 +0100, Sören Reinecke wrote:
> >> If these urls are following a fixed scheme like you mentioned then I
> >> see no need to add the urls
>
> if the url is stable (and this seems to be the case as it is hard-coded
> in the QR-code), i see an added value to be able to get
> the webpage from the stop.
>
> due the fact that the default relation isn't really in use,
> the advantages (having the information from the osm data) outweigh
> the disadvantages (having to delete or update the urls if they change
> unexpectedly)
>
> however this operation is geographically limited, so the author must
> ask the local community for their agreement, and not a global one
>
>
>
> ___
> 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: [OSM-talk] Duplicate Buildings

2023-03-12 Thread john whelan
Many thanks for putting some numbers on this.

Warin's comment would suggest it may also be more than just buildings that
are involved.

For buildings the total number as a percentage is small unfortunately they
tend to cluster so are more of a problem than if they were more spread out.

John

On Sat, Mar 11, 2023, 07:40 Frederik Ramm  wrote:

> Hi,
>
> I think an automatic fix of the problem is possible, however it would be
> a good idea to try and find out what the root cause of the problem is -
> bad software, bad imports, bad instructions?
>
> To get an idea of how big the issue is, I did this on a standard
> rendering database:
>
> create table buildings as (select way,osm_id from planet_osm_polygon
> where building is not null)
>
> select a.osm_id, b.osm_id into duplicates from buildings a, buildings b
> where a.osm_id < b.osm_id and a.way ~= b.way and st_equals(a.way,b.way);
>
> This took a few days - probably it could have been done more efficiently
> - and resulted in a list of about 70k buldings world-wide that are exact
> duplicates (geoetry-wise) of other buildings. The list is here:
>
> http://www.remote.org/frederik/tmp/duplicatebuildings.csv
>
> Some buildings are in OSM three or four times (contained i nthe above in
> the form of "a is duplicate of b, b is duplicate of c") but I've
> extracted them in extra files:
> http://www.remote.org/frederik/tmp/triplcatebuildings.csv and
> http://www.remote.org/frederik/tmp/quadruplicatebuildings.csv)
>
> I don't have the time to analyse the situation in more detail at present
> so if anyone wants to take the above lists as a basis for deeper
> analysis...
>
> Cheers
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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: [OSM-talk] Duplicate Buildings

2023-03-05 Thread john whelan
There are many and I have tools that can pick them out in a particular
area.  However to use them I inspect the building visually before deleting
one or the other.  Sometimes if the mapper has less than ten edits to their
name I may even skip adding a change set comment first.

However I do see many cases where the building or way appears to have been
uploaded twice and these I think could be handled by a bot which would save
my time and zap a substantial number.  I don't think anyone could object to
such an automated course of action whereas those that overlap really need
visual inspection to see which should be deleted.

Cheerio John

On Sun, Mar 5, 2023, 15:53 Isaac Boates  wrote:

> It might be better to check for building features which have a very large
> percentage of their area overlapping with another, rather than an exact
> duplicate, just in case there are a few kicking around that are identical
> except for one vertex
>
> Isaac
>
> On Sun, Mar 5, 2023 at 7:05 PM John Whelan  wrote:
>
>> Occasionally I come across a building that has been mapped twice.   A
>> number of them look as if they have been uploaded twice.
>>
>> Could some nice bot expert build one to run through the map and delete
>> any ways that are an exact duplicate even as far as the tags are concerned?
>>
>> The problem comes when doing population counts etc that rely on the
>> number of buildings in a given area.  A duplicated building means the wrong
>> number of vaccines etc get delivered to the area besides cluttering up the
>> map.
>>
>> Thanks John
>> --
>> Sent from Postbox <https://www.postbox-inc.com>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Duplicate Buildings

2023-03-05 Thread John Whelan
Occasionally I come across a building that has been mapped twice.   A 
number of them look as if they have been uploaded twice.


Could some nice bot expert build one to run through the map and delete 
any ways that are an exact duplicate even as far as the tags are concerned?


The problem comes when doing population counts etc that rely on the 
number of buildings in a given area.  A duplicated building means the 
wrong number of vaccines etc get delivered to the area besides 
cluttering up the map.


Thanks John
--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

2023-02-11 Thread john whelan
At first glance this seems a good idea but based on my experience as a HOT
validator you have to be careful.

Has the mapper changed their practices already?  Getting fifty emails
telling someone they used upper case two years ago might just put them off
mapping.

A better solution would be overpass the database for these sort of edits
done in the previous seven days.  Then flip one automated email noting the
accepted practice is XYZ but a bot will correct their edits.  If you can
grab the language of the mapper that might help here.

Cheerio John

On Sat, Feb 11, 2023, 13:24 Marc_marc  wrote:

> Le 11.02.23 à 18:41, Mateusz Konieczny via talk a écrit :
> > I propose to replace following surface tags by doing an automated edit:
>
> II agree with this automated edit.
>
> however, the most common cases should still be reported
> to the editors so that the error is corrected before sending
> and not by mass editing
> I don't know if it is possible but 2 rules could group many cases:
> surface= uppercase -> lowercase
> surface= space -> underscore
>
> Regaards,
> Marc
>
>
>
> ___
> 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: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

2023-02-11 Thread john whelan
Sounds wonderful.

John

On Sat, Feb 11, 2023, 12:49 Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> I propose to replace following surface tags by doing an automated edit:
>
> obvious typos:
>
> `surface=paving stones` → `surface=paving_stones`
> `surface=Paving_stones` → `surface=paving_stones`
> `surface=paving_stones:` → `surface=paving_stones`
>
> different form than standard surface value:
>
> `surface=wooden` → `surface=wood`
> `surface=cobblestones` → `surface=cobblestone`
>
> Polish name to English one:
>
> `surface=żwirowa` → `surface=gravel`
> `surface=kostka` → `surface=paving_stones`
> `surface=gruntowa` → `surface=unpaved`
>
> English vs very close to English but actually different:
>
> `surface=asfalt` → `surface=asphalt`
>
> Edit would be automatic, rerun from time to time, split into small
> changeset by geographic areas and run by
>
> https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history%20bot%20account
>
> Why it is useful? It helps newbies to avoid becoming confused. It
> protects against such values becoming established. Without drudgery
> that would be required from the manual cleanup. It also makes easier to
> add missing surface= values
>
> Why automatic edit? I have a massive queue (in thousands and tens of
> thousands) of automatically detectable issues which are not reported by
> mainstream validators, require fixes and fix requires review or
> complete manual cleanup.
>
> There is no point in manual drudgery here, with values completely useless.
>
> This values here do NOT require manual overview. If this cases will
> turn out to be an useful signal of invalid editing than I will remain
> reviewing nearby areas where bot edited.
>
> And I fixed some manually and they were not a great sign of a problematic
> data.
>
> Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
> map data quality will improve.
> ___
> 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: [OSM-talk] Adoption of OSM geometry as state mapping base

2023-02-09 Thread john whelan
I think the issue is more fit for the purpose.

For critical work the OSM database cannot be relied upon.  We have too many
inexperienced mappers who can inadvertantly corrupt the map.  There are
processes to allow an area to be watched so a mapper can double check any
changes in a specific area.  The map is vandalised from time to time.  The
DWG does a great job but the problem is it cannot be relied upon 100% of
the time as errors will be present until they are removed.

Having said that Stats Canada is quite happy to use building data in Canada
on the basis it is the best available.

So it's better than nowt.  It's fairly easy to add Open Data to it either
directly or download a sample and mix the open data in that way.  I think
some if the NGOs work like that.

The wording is probably to protect OSM from law suits, we don't guarantee
the quality of the data will be good enough for your purposes.

You can run your own database by the way.  Grab a chunk of the map and run
your own updates into it.  This has the advantage that you can use all the
OSM tools and is reasonably well documented.

Going the Legal Working Group path can be lengthy.  They are practically
all volunteers and they have a back log.

So do your TRA (Threat Risk Analysis) and see what you think.  Remember
lawyers are paid to be cautious.

Cheerio John

On Thu, Feb 9, 2023, 19:43 rob potter  wrote:

> Hi,
>
> I am representing the state transport department Department of Transport
> and Planning (Victoria, Australia) - OpenStreetMap Wiki
> 
>  and
> we are looking to consume the OSM road & rail networks for our operations.
>
> *Lawyers have raised a concern about these conditions, as the road data
> use is supplied to our emergency services fire and ambulance.  We have not
> started using the information but we are implementing a system of
> validation and change detection, then produce an authoritative version for
> other agency consumption.*
> *Unlawful and other unauthorized uses include a clause "Operate dangerous
> businesses such as emergency services or air traffic control, where the use
> or failure of the Services could lead to death, personal injury or
> significant property damage;" and "Store data available through the
> Services in order to evade these Terms (including aiding anyone else in
> doing so); or"*
>
> Please any advice would be greatly appreciated, ultimately we will enhance
> the overall content of OSM in the Victoria, but really do not want to cause
> problems later.
>
> Thanks,
>
> Rob
> ___
> 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: [OSM-talk] Should we be mapping transformers and powerlines?

2023-01-19 Thread john whelan
I seem to recall there are fewer rifles per head of population in the UK.
The problem is more a North American one although with the ease of which
guns can be 3D printed it could be a UK eventually.

On a side issue I wonder if Microsoft's building detector could pick out
telephone boxes in the UK?

Cheerio John

On Thu, Jan 19, 2023, 12:40 Nick Whitelegg 
wrote:

>
> Even still, the location of major substations (e.g the 400-132kv type)
> isn't really a secret. I could reel off quite a few in the UK without even
> looking at a map.
>
> Nick
>
>
> ------
> *From:* john whelan 
> *Sent:* 19 January 2023 17:38
> *To:* Nick Whitelegg 
> *Cc:* OpenStreetMap talk mailing list 
> *Subject:* Re: [OSM-talk] Should we be mapping transformers and
> powerlines?
>
> I accept powerlines are fine and visible on other maps but the case for
> transformers isn't quite so strong.
>
> Cheerio John
>
> On Thu, Jan 19, 2023, 12:15 Nick Whitelegg via talk <
> talk@openstreetmap.org> wrote:
>
>
> I thought the whole point of OSM was to map the ground truth?
>
> Power lines are there, and they are an important navigational aid when out
> walking or hiking.
>
> And besides, just about every commercial mapping provider that I've used
> shows them. The OS does, as do maps that I've seen in a range of
> continental European countries.
>
> Nick
>
>
> --
> *From:* john whelan 
> *Sent:* 19 January 2023 03:03
> *To:* OpenStreetMap talk mailing list 
> *Subject:* [OSM-talk] Should we be mapping transformers and powerlines?
>
> Apparently you can do a lot of expensive damage by firing a rifle bullet
> through them as happened more than once in the US and given the situation
> in Europe at the moment is there a risk that something similar could happen
> there?
>
> Should we have a process that says some things should not be mapped?
>
> I seem to recall that the location of the pipeline that supplies aviation
> fuel to airports is considered an official secret in the UK.
>
> Thoughts?
>
> Thanks John
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk=05%7C01%7Cnick.whitelegg%40solent.ac.uk%7C976f4ceec26941fdf68a08dafa43f19b%7Cd684e4cd491a4577bf33546478d72e3c%7C0%7C0%7C638097466969506677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Wnt8Dqlivd%2F9kn3Npf%2BfPSCc2w8ZSGkGBI1hNvtsuRc%3D=0>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Should we be mapping transformers and powerlines?

2023-01-19 Thread john whelan
I accept powerlines are fine and visible on other maps but the case for
transformers isn't quite so strong.

Cheerio John

On Thu, Jan 19, 2023, 12:15 Nick Whitelegg via talk 
wrote:

>
> I thought the whole point of OSM was to map the ground truth?
>
> Power lines are there, and they are an important navigational aid when out
> walking or hiking.
>
> And besides, just about every commercial mapping provider that I've used
> shows them. The OS does, as do maps that I've seen in a range of
> continental European countries.
>
> Nick
>
>
> ------
> *From:* john whelan 
> *Sent:* 19 January 2023 03:03
> *To:* OpenStreetMap talk mailing list 
> *Subject:* [OSM-talk] Should we be mapping transformers and powerlines?
>
> Apparently you can do a lot of expensive damage by firing a rifle bullet
> through them as happened more than once in the US and given the situation
> in Europe at the moment is there a risk that something similar could happen
> there?
>
> Should we have a process that says some things should not be mapped?
>
> I seem to recall that the location of the pipeline that supplies aviation
> fuel to airports is considered an official secret in the UK.
>
> Thoughts?
>
> 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


Re: [OSM-talk] Should we be mapping transformers and powerlines?

2023-01-19 Thread John Whelan
I suspect you can do a lot less damage to a concrete dam with a rifle 
than a transformer.


As long as we have discussed the matter I think that is all that 
matters. I'm happy and content.


Worse case scenario

A guy called Putin has been targeting them in Ukraine.  Copycat.

Someone shoots out a dozen at minus 20c, two can cut off electricity to 
a city of a million people.  One or two you can replace quickly a dozen 
at the same time you're talking months to restore power.


What sort of idiot would do that?  Well one or two people don't exactly 
love America.  One of the drug cartels whose boss is imprisoned in the US?


Then you have those that would like to overthrow the government or do it 
just for kicks.


Have fun

Cheerio John

Clifford Snow wrote on 1/18/2023 10:35 PM:



On Wed, Jan 18, 2023 at 7:05 PM john whelan <mailto:jwhelan0...@gmail.com>> wrote:


Apparently you can do a lot of expensive damage by firing a rifle
bullet through them as happened more than once in the US and given
the situation in Europe at the moment is there a risk that
something similar could happen there?

Should we have a process that says some things should not be mapped?

I seem to recall that the location of the pipeline that supplies
aviation fuel to airports is considered an official secret in the UK.

Thoughts?


I live in one of the states where people fired at and damaged a power 
substation so I'm concerned about the safety of our infrastructure. 
Unfortunately there are many infrastructures that are vulnerable to 
attacks. Such facilities as water plants, dams, bridges, 
transportation, pipelines, hospitals, and a host of others. But I 
believe that mapping them can also help. If you go back to the idea 
that "security through obscurity" I think you'll find that it is just 
an illusion.


BTW - those caught and charged with damaging a power substation here 
were looking to rob some stores. We all assumed it was right wing 
radicals.


Best,
Clifford

--
@osm_washington
www.snowandsnow.us <https://www.snowandsnow.us>
OpenStreetMap: Maps with a human touch


--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Should we be mapping transformers and powerlines?

2023-01-18 Thread john whelan
Perhaps you could expand on the benefits of mapping them?

Thanks John

On Wed, Jan 18, 2023, 10:09 PM stevea,  wrote:

> I'd like to say "oh, please..." because this seems a bit harsh.  But I
> understand that people can be sensitive.
>
> But this is OSM and I'd like to believe we live in a world that is more
> free rather than less free.  What's next, do we stop mapping pre-school or
> kindergartens because they have children?
>
> Criminals are going to use maps, yes, that is going to happen.  We mappers
> ourselves are not criminals for mapping.
>
> Map.  Map well.  Criminals will be criminals.  While there are book
> banning people, librarians are not criminals.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Should we be mapping transformers and powerlines?

2023-01-18 Thread john whelan
Apparently you can do a lot of expensive damage by firing a rifle bullet
through them as happened more than once in the US and given the situation
in Europe at the moment is there a risk that something similar could happen
there?

Should we have a process that says some things should not be mapped?

I seem to recall that the location of the pipeline that supplies aviation
fuel to airports is considered an official secret in the UK.

Thoughts?

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


Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

2022-11-29 Thread John Whelan

It was merely in response to Greg Troxel's comment.

"In the case of your transit system, what were the key problems, and how
were they overcome?  I suspect that history is very useful for others."

Cheerio John


Dave F wrote on 11/29/2022 3:13 PM:

Sorry, but I'm unclear what that detailed story has to do with my point?

DaveF

On 29/11/2022 16:54, John Whelan wrote:


The story of the Ottawa bus stops...





--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

2022-11-29 Thread John Whelan
The story of the Ottawa bus stops started when the City decided to 
announce the bus stops in an automated way to assist blind people. To do 
this they went round every bus stop with very accurate GPS equipment so 
the bus stops were measured to within a meter or so accuracy. One or two 
weren’t in quite the right place, being placed in the highway but on the 
whole they were much better than they had been.


Some GTFS files for bus stop positions can be 200 meters out.

I bumped into the head of the transit system and talked about the 
License on the data and his comment was “but we want you to use the data.”


So now we had accurate bus stop data that we couldn’t use because of 
licensing. Bus stop data in OpenStreetMap in Ottawa is important because 
the transit route planning system at the time did not use footpaths and 
would suggest a longer trip to a different bus stop than the closet one.


The Canadian Treasury Board was promoting Open Data and the President of 
the Treasury Board wanted to show how progressive they were so had a 
meeting of a dozen or so people who were thought to use Open Data. I was 
one of them and raised the issue that we couldn’t use their data because 
of the license which surprised a few civil servants who were there.


It took them five years to consult and eventually come up with version 
2.0 of the Open Government Licence – Canada which is the current Open 
Data License.


Statistics Canada sells a lot of data. Want to know where the best place 
to open a new coffee shop is Stats Canada will sell you all sorts of 
data to show you were the best places are. They were interested in 
enriching their data about buildings. How many floors they had etc. and 
had the idea that using OpenStreetMap volunteers would be an inexpensive 
way to enrich their data. Before I retired I worked at Statistics Canada 
and the corporate culture is very different to OpenStreetMap.


We had a meeting which included the City of Ottawa, a couple of people 
from the local University, at least one person from HOT by phone and 
someone from Metrolinx who had added some addresses from Statistics 
Canada’s OpenData portal after examining their Open Data license and the 
requirements of OSM. They were new houses and they wanted them for their 
transit planner. Statistics Canada Open Data is released under the 
Federal government’s Open Data license by the way.


We showed them Ottawa in OSMand in French with French street names, 
politically French is important in Canada and can add expense to a 
project if you need to translate etc. The decision in principle was made 
to import City of Ottawa’s building data into OSM and then enrich it.


It took two years to change the City’s Open Data license to be the same 
as the Federal Government one. There are minor wording changes such as 
City of Ottawa rather than the Crown but basically it’s the same.


During that time I suggested to Statistics Canada someone attending SotM 
in Europe might be useful to make a few contacts. In the event the 
person who was suppose to go was unable to attend was unable to attend 
so his manager went instead.


So everything was lined up ready for the import. Both the City of Ottawa 
and Statistics Canada had put a lot of effort into the project and many 
organisations were looking forward to using the data. Metrolinx had 
studied the licensing and were happy we were OK.


The license was challenged on the import mailing list. Shall we simply 
say the LWG was very nice and came up with a verdict that accepted 
Version 2 of the Open Data license. We’ll pass over all the people 
involved but simply say it took considerable effort and resources.


These days data from most Canadian municipalities released under their 
Open Data license is not eligible for OSM but the same data released 
through the Statistics Canada Open Data is eligible.


The bus stops, well once the Open Data licenses had been sorted out the 
local mappers imported the data.


Any change to the license requirements to import Open Data can have an 
impact and that is a concern. It takes a long time to get things changed 
to line up.



Cheerio John

Dave F via talk wrote on 11/29/2022 10:38 AM:

On 28/11/2022 23:48, Tobias Knerr wrote:
we would like to offer data donors a standard legal text that they 
can use to make their data available to OSM in such a way that we 
would expect it to survive a hypothetical license change.


I'm confused.
If a maintainer of a database wishes to change their licence, they're 
certain to have justifiable reasons for doing so. If it means OSM 
can't use it, so be it. OSM has no jurisdiction.


If it's a licence change by OSM then how can a maintainer of a 
database possibly account for a future, unspecified change who's 
implementation was out of their control?


Could you expand on what you mean by 'legal text'. Is it a legally 
binding contract?


Cheers
DaveF


___
talk mailing 

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

2022-11-28 Thread john whelan
I have concerns about the amount of effort we seem to be asking open data
set creators to make.  I think it took me seven years to get the licensing
correct to be able to import the local bus stops and very early in the
process the head of the transit system said 'but we want you to use our
data.'

Cheerio John

On Mon, Nov 28, 2022, 2:18 PM Amanda McCann, <
amanda.mcc...@osmfoundation.org> wrote:

> Hello fellow OSMers.
>
> As you are no doubt aware, OSM requires that data imports be listed on the
> OSM Wiki ( https://wiki.openstreetmap.org/wiki/Import/Catalogue ),
> including if the source is “ODbL OK status”.
>
> At the Nov. 2022 OSMF Board meeting (25 Nov), the Board voted that imports
> should, from now on, list whether the data source is compatibly (or
> incompatible) with the OSM Contributor Terms¹.
>
> The Board has also budgeted to commission a template that OSMers can use
> to request that data sources release their data under those terms. That
> will obv. follow later. However given that OSM is mostly volunteer run, I
> don't know if/when that will be ready for you.
>
> The minutes of the meeting have not yet been written, nor accepted, but
> when they are (in about a month), you will find the specifics here):
> https://wiki.osmfoundation.org/wiki/Board/Minutes/2022-11
>
> ¹
> https://wiki.openstreetmap.org/wiki/Open_Database_License/Contributor_Terms
>
> --
> A. McCann
> Secretary
> OpenStreetMap Foundation
>
> Name & Registered Office:
> OpenStreetMap Foundation
> St John’s Innovation Centre
> Cowley Road
> Cambridge
> CB4 0WS
> United Kingdom
> A company limited by guarantee, registered in England and Wales
> Registration No. 05912761
>
> ___
> 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: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store

2022-11-27 Thread john whelan
I forget where but it has been said that it is legal and that is the reason
JOSM is now available via the store.

Cheerio John

On Sun, Nov 27, 2022, 11:43 PM James,  wrote:

> IANAL but GPL v2 does allow to charge for distribution. Is it ethical, lol
> no, would lawyers care? Probably not
>
> On Sun, Nov 27, 2022, 11:30 PM stevea  wrote:
>
>> Yes, thanks much, James!  (For linking "Reporting Infringement to
>> Microsoft").  I do wonder if simply forking and charging money for existing
>> open-source software is an egregious slap in the face to OSM (JOSM
>> developers, especially), although I'm not an attorney.  So, I'd urge our
>> LWG / legal-beagles to take a look at this, please.
>>
>> On the other hand, if there is something "value-added" to the fork that
>> justifies charging money, maybe it's OK.
>>
>> > On Nov 27, 2022, at 8:26 PM, James  wrote:
>> >
>> > https://www.microsoft.com/en-us/legal/intellectualproperty/infringement
>> >
>> > On Sun, Nov 27, 2022, 11:15 PM john whelan 
>> wrote:
>> > You can only leave a review if you download the software.
>> >
>> > Both are JOSM, one is a fork which costs money which goes to the person
>> who created the fork the other is normal JOSM which is free.
>> >
>> > Cheerio John
>> > 
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store

2022-11-27 Thread john whelan
You can only leave a review if you download the software.

Both are JOSM, one is a fork which costs money which goes to the person who
created the fork the other is normal JOSM which is free.

Cheerio John

On Sun, Nov 27, 2022, 11:01 PM stevea,  wrote:

> If choosing which version is "legitimate" (or preferred) is important, and
> "leaving a review" is a (one) method for communicating that, I would
> underscore that if you do leave a review, make very clear how one differs
> from the other.
>
> On Nov 27, 2022, at 5:33 PM, john whelan  wrote:
> >
> > Agreed but some do and currently both have one review each so it isn't
> that clear which is the official OpenStreetMap editor.
> >
> > Even a couple more reviews would help.
> >
> > Thanks
> >
> > Cheerio John
> 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store

2022-11-27 Thread john whelan
Agreed but some do and currently both have one review each so it isn't that
clear which is the official OpenStreetMap editor.

Even a couple more reviews would help.

Thanks

Cheerio John

On Sun, Nov 27, 2022, 20:27 James  wrote:

> not everyone runs winblows
>
> On Sun, Nov 27, 2022, 8:19 PM John Whelan  wrote:
>
>> On a windows machine do a search for Microsoft store.  Then search for
>> JOSM.  Download it then you can leave a review.  The more reviews it has
>> the more it looks as if it is the legitimate version.
>>
>> The other version which is a fork of JOSM is called  OpenStreetMap editor
>> and has a JOSM screen shot and costs $5.99 can.
>>
>> Thanks John
>>
>> Dave F wrote on 11/27/2022 7:15 PM:
>>
>> Link(s)?
>>
>> On 30/10/2022 18:47, john whelan wrote:
>>
>> There are two versions of JOSM available on the Microsoft store.  One is
>> a fork and costs money the other is the kosher version.
>>
>> It might be helpful if JOSM had a few reviews to make it stand out from
>> the other version.
>>
>> Thanks John
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>>
>> --
>> Sent from Postbox <https://www.postbox-inc.com>
>> ___
>> 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: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store

2022-11-27 Thread John Whelan
On a windows machine do a search for Microsoft store.  Then search for 
JOSM.  Download it then you can leave a review.  The more reviews it has 
the more it looks as if it is the legitimate version.


The other version which is a fork of JOSM is called  OpenStreetMap 
editor and has a JOSM screen shot and costs $5.99 can.


Thanks John

Dave F wrote on 11/27/2022 7:15 PM:

Link(s)?

On 30/10/2022 18:47, john whelan wrote:
There are two versions of JOSM available on the Microsoft store.  One 
is a fork and costs money the other is the kosher version.


It might be helpful if JOSM had a few reviews to make it stand out 
from the other version.


Thanks John


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




--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Rent-a-crowd needed JOSM Microsoft store

2022-10-30 Thread john whelan
There are two versions of JOSM available on the Microsoft store.  One is a
fork and costs money the other is the kosher version.

It might be helpful if JOSM had a few reviews to make it stand out from the
other version.

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


Re: [OSM-talk] I need your help please

2022-09-19 Thread john whelan
The changes have been made to the central database.  The tiles or rended
image are recreated later sometimes a few days later.

There is an off line version of the database created roughly roughly once a
day at geofrabrik.de from which you can create your own set of tiles etc.
Depending how urgent it is.

Cheerio John

On Mon, Sep 19, 2022, 5:42 AM Fakhreddine Azzouni, <
azzounifakhredd...@gmail.com> wrote:

> Good afternoon, I started using OSM for a tourism project. The idea is
>  make a tour's road map with places from OSM. But some places are not on
> the map so I added them yesterday. I am using a WordPress Plugin to get
> locations From OSM. Unfortunately I couldn't find any of the locations I
> have recently added.
> As this matter is urgent, I would appreciate a reply as soon as possible.
> ___
> 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-transit] [Talk-GB] Mapping train services in Great Britain

2021-06-01 Thread john whelan
One problem I had when living in the UK was deciding which station to use
to travel up to London.  Mother who worked as a midwife had been told one
station by the nurses at the hospital.  Fine except it was a 20 minute
drive to get there and the fairly high frequency but stopping tube would
get you into the city fairly quickly.  Later I used the station that was
ten minutes walk away.  That saved the 20 minute drive and has fewer stops
at stations.  Years later I found another station 15 minutes walk away that
ran into Liverpool street with only one stop.  Much the fastest but I'd
been living there more than ten years before I uncovered it.  There was
another line I used occasionally that ran into Kings Cross and occasionally
that would best depending on where you were going to.

So it is a mixture sometimes of which station to use and how that gets you
to your destination.  Don't get me started on tickets and which to use.

The route planners make it much easier than obtaining the old paper
timetables and pouring through them.

Does all this complexity belong in OSM?  Probably not our strength I think
is in the mapping of stations etc and let someone else sort the rest out.

Cheerio John



On Tue, Jun 1, 2021, 11:29 Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> What's wrong with consulting a timetable?
>
> Maps show you where you can go, timetables tell you when .
>
> DaveF
>
> On 01/06/2021 01:18, Michael Tsang wrote:
>
> > I think you are missing the point that GB is not a city.
>
> > Cities are densly pack and urban transport systems reflect this. In
> London tube trains simply stop at every station.
>
> > This structure will not work when it comes to rural stations, and what
> we have works very well. It would not be efficient to stop every trains
> at stations which only have a few dozen passengers in a day.
>
> Other European countries are doing it much better. The routes are
> numbered. There are designated express services with stops only in big
> cities. The rural stations have only local stopping services which call at
> every stop en-route.
>
> We don't even have a useful route map from train companies that can work
> out which train I should take without consulting the timetable.
>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [OSM-talk] JOSM on Raspberry pi 4

2020-12-21 Thread John Whelan

Thank you for the process.

Cheerio John

James wrote on 2020-12-21 19:15:

wget https://josm.openstreetmap.de/josm-latest.jar

java -jar josm-latest.jar

in a terminal

On Mon., Dec. 21, 2020, 7:13 p.m. John Whelan, <mailto:jwhelan0...@gmail.com>> wrote:


I don't know enough about the pi to know where to copy it to.
Getting the latest .jar isn't a problem.

Thanks John

James wrote on 2020-12-21 19:11:

https://josm.openstreetmap.de/josm-latest.jar

java -jar josm-latest.jar

On Mon., Dec. 21, 2020, 7:10 p.m. John Whelan,
mailto:jwhelan0...@gmail.com>> wrote:

It seems to load from "sudo apt-get install josm" but it is
version 14760. thank you Martin Bone you tube. I'm not too
sure where to download the new .jar file to get it to a more
recent version. So technically it will work. The big question
then becomes is it useful? Low power but needs a screen. Can
we leverage it in anyway? I'm thinking if it gets into
schools it might be useful but if it needs a more powerful
machine than the school might purchase can we nudge up the
specs in someway? I know you can use a smartphone but JOSM is
a bit more powerful and you can grab a bit of osm compress it
then load it up on the pi. Not real time but in areas where
there is little activity a 3 or 4 day old file might well be
good enough. I'm thinking Africa here. Solar panel into a
powerbank, run the pi from a powerbank. On a slightly larger
scale solar panel into an instant pot with battery, gives you
enough power to run a pi as well. Instant pots have been run
from solar with battery, the 3 quart pot requires a lower
power level. Can someone come up with a mixture that would
work? Thanks Cheerio John
Oliver Simmons wrote on 2020-12-21 18:48:


You’ll want to turn as much rendering off in JOSM as you can.

Mainly:

1. Disable “Draw boundaries of downloaded area” (This is a
big performance hit for some reason)

2. OSM Data -> Options that affect drawing performance -
disable both antialiasing options.

3. OSM Data -> ditto - “Hide labels when dragging the map”
may also help.

AFAIK other options won’t make much difference, those are
just the main three.

You may also want to experiment with styles, some (such as
“Advanced lane & road attributes” will put a lot more load
on rendering due to their complexity and the transparent parts.

With the RAM & speed upgrades on the Pi4, downloading a lot
of data shouldn’t be much of an issue, only if you try to
look at it all at once.

―

- Oliver Simmons [https://goodclover.xyz]

*From: *John Whelan <mailto:jwhelan0...@gmail.com>
*Sent: *21 December 2020 11:30 PM
*To: *OpenStreetMap <mailto:talk@openstreetmap.org>
*Subject: *[OSM-talk] JOSM on Raspberry pi 4

Has anyone tried it?  My thoughts run along the lines of the
pi 400 which has 4 gigs of memory might be interesting,
there are pi4s with 8 gigs available.

If so how do you install it and run it.

Thanks John

-- 


Sent from Postbox <https://www.postbox-inc.com>



-- 
Sent from Postbox <https://www.postbox-inc.com>

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


-- 
Sent from Postbox <https://www.postbox-inc.com>




--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] [Osmf-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

2020-12-09 Thread john whelan
In the diverse collection of people we have in OSM you will be hard pressed
not to offend someone.  The views held are very diverse.  Traffic_signal or
traffic_light tagging us an example of very diverse views.  I'm sure
someone will be along and give me the correct way to tag shortly.

I hadn't realised the name Kathleen was one that either gender could use
and I apologise for making an assumption about the gender of the person
using it.

Cheerio John

On Wed, Dec 9, 2020, 16:00 Clay Smalley  wrote:

> I'm noticing a pattern here in the replies to this email:
>
> Only men have replied. This is, unfortunately, par for the course on the
> OSM mailing lists. The lack of discussion by non-men is an undeniable fact.
> The simplest explanation for this is the systematic institutional hostility
> towards women in the OSM community. The replies themselves are the best
> evidence of this.
>
> These men replying have taken it upon themselves to explain to a woman
> what constitutes misogyny. News flash: you do not get to decide what
> offends other people. If you are a man, misogyny will never happen to you
> by definition. If you are a man, you have never been, are not, and will
> never be a victim of misogyny. This isn't your area of expertise. Listen to
> the experts.
>
> Some men replying have even mentioned how this draft letter hurts their
> feelings. These men need to slow down and consider for a moment that their
> temporarily hurt feelings are less important than the safety of women.
> Men's feelings are irrelevant to issues where women are victims.
>
> As far as I know, various OSM-affiliated groups have codes of conduct, but
> there isn't one governing these mailing lists. We need to adopt a code of
> conduct yesterday.
>
> -Clay (they/them)
>
> On Wed, Dec 9, 2020 at 2:13 PM Celine Jacquin  wrote:
>
>> Hello everybody
>> I hope you are all well
>>
>> We, several groups, chapters, organizations and individuals, have reacted
>> to the conversation in the osm-talk-list (
>> https://lists.openstreetmap.org/pipermail/talk/2020-December/085692.html)
>> considering that it is an incident symptomatic of the problem we have faced
>> for many years in the community, which is one of the greatest obstacles to
>> diversity at all levels of OSM. Time to make a real change.
>> That is why we have developed a beginning of statement on the desirable
>> mechanisms to work solidly on the rules of coexistence and improve
>> diversity.
>>
>> We bring it to your attention and invite anyone who feels represented to
>> sign it. Translations are in preparation (any help is welcome):
>>
>> https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit?usp=sharing
>>
>>
>> On behalf of the signatories
>> Best regards
>>
>> Céline Jacquin
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] [Osmf-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

2020-12-09 Thread john whelan
No but I am suggesting dealing with it is complex and has to be done over
time.  Do you ban jargon for example?

The danger in Celine's confrontational approach is we throw the baby out
with the dish water.

You have an interesting mind and know the background.  How would you
approach this?

And yes I admit to being white male etc.

Many Thanks for your thoughts.

Cheerio John

On Wed, Dec 9, 2020, 15:45 Kathleen Lu  wrote:

> > Many females do not map using their own name but will use a male
> sounding name to avoid problems.
>
> John, are you seriously citing this as evidence that there is not
> pervasive misogyny in the OSM community?
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Call to Take Action and Confront Systemic Offensive Behavior in the OSM Community

2020-12-09 Thread John Whelan
The issue of diversity is complex.  In Africa many of the locals whilst 
feeling that it would be nice to have all local mappers they recognise 
that the map would not be as complete without the armchair mappers.


Unfortunately when you work in technical areas often you'll see a group 
build up expertise over time.  These people have the frame work if you 
like to to see how things fit together and it is how things like 
overpass have come about.


Fredrick is one of those people who has a great deal of knowledge and 
OpenStreetMap would be much poorer without him.


It does take time to build up expertise and to take part in the 
discussions in a meaningful way.  However using terms such as "*This 
power dynamic leads to a communication style which includes 
misogynistic, hostile, targeting, doxing, unfriendly, competitive, 
intimidating, patronising messaging, which is offensive to us and forces 
many of us to remain as observers and without the confidence to 
participate actively" I think is purely destructive. Recognise that some 
of the wording you will come across is pure jargon. It works because the 
group the communication is taking place is to some extent closed and 
jargon gets the message across effectively and quickly. Communication 
that is more general does need the "can a six year old understand this 
approach". *
I also have an issue with expecting everyone to conform to a set of 
social norms, I can think of at least one mapper who is obsessive over 
tiny details and goes to great lengths to get them right on the map.  
However his social interactions may seem a bit abrupt to some.  His 
mapping contributions though are extremely valuable.


I also have an issue with those who say we don't have enough female 
mappers. Many females do not map using their own name but will use a 
male sounding name to avoid problems.  Hence you cannot say with any 
accuracy just how many mappers are male orfemale.


If you feel that OpenStreetMap is not open enough then there are forks 
that you can join inor you can build your own.


OpenStreetMap does respect local mappers points of view, which I think 
addresses your comments about minorities. Which is why the map uses 
different conventionsin different places.


However that brings us back to the problem of how decisions are made.  
Certainly in Africa the NGOs have played a part in pushing for 
consistent tags and tagging standards and I am happy to accept that 
those who coordinated the efforts where often white, etc etc but they 
did consult with everyone who would talk to them.  Things like purdah 
can be an issue.  Communicating through a six year old because his 
mother was in purdah means mother's views may not be communicated easily.


Cheerio John


Celine Jacquin wrote on 2020-12-09 14:06:

Hello everybody
I hope you are all well

We, several groups, chapters, organizations and individuals, have 
reacted to the conversation in the osm-talk-list 
(https://lists.openstreetmap.org/pipermail/talk/2020-December/085692.html) 
considering that it is an incident symptomatic of the problem we have 
faced for many years in the community, which is one of the greatest 
obstacles to diversity at all levels of OSM. Time to make a real change.
That is why we have developed a beginning of statement on the 
desirable mechanisms to work solidly on the rules of coexistence and 
improve diversity.


We bring it to your attention and invite anyone who feels represented 
to sign it. Translations are in preparation (any help is welcome):

https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit?usp=sharing


On behalf of the signatories
Best regards

Céline Jacquin


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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] time to review

2020-12-02 Thread john whelan
I would suggest that if someone could identify a list of mapping tasks
suitable for beginners that might help this sort of thing happening again.

I'd done a fair amount of validation of HOT tasks in the past which I'm
sure are similar and I'm more than aware of the amount of effort needed to
validate after new untrained enthusiastic mappers have been mapping.
Especially when they map only a couple of times.

I'm also aware that it does take a lot of knowledge and resources to clean
up afterwards.

Do we need a half page introduction to OSM?  Something along the lines of
if you are organising some sort of mapathon these are things you need to
consider and theses are the sort of things that have caused problems in the
past.  I get the feeling the enthusiastic organisers are going to do it
anyway but it help help a bit.

It doesn't help the present situation but it might help prevent more
problems in the future.

Cheerio John


On Wed, Dec 2, 2020, 16:29 Mario Frasca  wrote:

> Hi Rory,
>
> let's include the list, so you're talking with the whole community, not
> just to me.
>
> BACKGROUND: we're trying to have the YouthMappers Chapter of the
> University of Panama consider they're mapping within OSM, that there's a
> local community of mappers already mapping, and with some experience in
> different fields.
>
> unfortunately, the YMUP Chapter refuses to reply to comments to their
> changesets, or to consider complaints about their low quality of edits, and
> the sheer mass of beginners they throw into not-too-simple tasks.  recently
> they had their yearly "Gis Day", please don't ask me what it is, because I
> don't know, only that there's a hashtag being used once a year by the
> YouthMappers UP Chapter.  also please don't ask me who's inside this
> chapter, because I don't know.
>
> when Mateusz wrote to i...@youthmappers.org about their organized editing
> activity without declaration of intents, the result of his writing was that
> HOT opened two projects on top of two areas we from the community were
> editing using the tasking manager from tareas.openstreetmap.co, forcing
> us to clean up the edits while they were coming in.  that's Santiago and
> Colón.
>
> in Santiago we reverted several changesets, and made the effort to close
> their project so they would stay away from the work which was anyway almost
> complete.
>
> in Colón we stopped editing downtown, leaving it to the YMUP Chapter.
>
> there's still no published plan from the chapter, Rory says that they are
> reviewing the tasks they had opened, but apart from beginner mapper
> agreenish , arguably adding
> to the mass of mistakes, I don't see much editing activity in either
> project.
> I will write a diary entry, with images, and will try to make it a
> structured presentation of what goes on here.  there's statistical data
> I've collected that shows just how organized the edits from YMUP, and I
> find it quite insulting, the mismatch between the words by YouthMappers
> International, the call for patience by HOT, and the continued
> self-boasting by this local Chapter, while we need to do the cleaning up.
>
> you know … I am editing Morocco, that's more relaxing.  hopefully no
> YouthMappers there.
>
> ciao,
>
> Mario
>
>
> On 02/12/2020 15:52, Rory Nealon wrote:
>
> Hi Mario,
>
> Sorry for not getting back to you sooner.  I will try and contact the
> chapter and get an answer for you.  The last I heard was that they had
> begun to validate the tasks they had created.
>
> Cheers,
>
>
> Rory
>
> On Sun, Nov 29, 2020 at 4:53 PM Mario Frasca  wrote:
>
>> Dear Rory,
>>
>> let me insist, I wish to have an estimate of how long we should wait,
>> for the YMUP to review their edits?
>>
>> as you have read from his complaint to YMI, Markusz assumes something
>> like "at the end of the day", even if he wrote the complaint 4 days
>> after the edit — which he fixed himself.
>>
>> maybe too strict myself, because I would say "the next day", which could
>> be "the next available day".
>>
>> in particular since this looks like episodic edits, not ongoing
>> activities.
>>
>> so, what is the time we should allow before concluding they abandoned
>> the location?
>>
>> a week?  (slow, but could fit in a low activity group)
>>
>> a month?  (very slow, one forgets what they were doing)
>>
>> a year?  (ah? next group, please?)
>>
>> best regards, Mario Frasca
>>
>>
>
> --
> *Rory Nealon (he/him)*
> *Senior GIS Analyst & YouthMappers Activity Manager*
> *US Agency for International Development*
> *Washington, DC*
> *+1 202.468.7890*
> *GeoCenter MyUSAID Site *
>
> *The Geographic Approach to Development
> *
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

Re: [Talk-ca] mapping Ottawa light rail stations.

2020-11-25 Thread John Whelan
It looks like the entrances railway=subway_entrance  have been mapped 
but the optional name tag hasn't been added in all cases.  Without the 
name OSMAND struggles to find them.  Parliament subway entrance for 
example is searchable.


If someone is passing (Danny?) could they add the names to the subway 
entrances please.  I'm unable to figure out what they should be.  Lyon 
is missing the names, Parliament has everything labelled parliament. 
Dunno about the others.


Thanks John

Jeff McKenna wrote on 2020-11-25 07:45:
You can ask the OsmAnd community directly in their forum, which is 
quite vibrant: https://groups.google.com/g/osmand/


-jeff





--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] mapping Ottawa light rail stations.

2020-11-24 Thread John Whelan
I'm more interested in being able to say to OSMAND get me from a 
specific exit whatever to a street address and I couldn't figure out how 
to do that.


Cheerio John

James wrote on 2020-11-24 19:30:
I don't think osmand handles elevators, there's a issue open on github 
to support indoor mapping, but it's been flagged as a "nice to have"


On Tue., Nov. 24, 2020, 7:22 p.m. John Whelan, <mailto:jwhelan0...@gmail.com>> wrote:


Today I wanted to use OSMAND+ to work out the by foot from Lyon
station to 60 Cambridge street.  There are two entrances / exits
to the station and I wanted to leave by a particular exit.  The
most westerly one.

The route suggested by OSMAND+ was at first glance bizarre but
looking more closely seems to follow the underground foot ways
from the platform level which is fine except I was interested in
using the elevators.  So how do I tell OSMAND+ I wish to go from a
particular street level exit?

The second question is should the exits be marked on the map in
someway that OSMAND can find?

Thanks John
-- 
Sent from Postbox <https://www.postbox-inc.com>

___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca



--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] mapping Ottawa light rail stations.

2020-11-24 Thread John Whelan
Today I wanted to use OSMAND+ to work out the by foot from Lyon station 
to 60 Cambridge street.  There are two entrances / exits to the station 
and I wanted to leave by a particular exit.  The most westerly one.


The route suggested by OSMAND+ was at first glance bizarre but looking 
more closely seems to follow the underground foot ways from the platform 
level which is fine except I was interested in using the elevators.  So 
how do I tell OSMAND+ I wish to go from a particular street level exit?


The second question is should the exits be marked on the map in someway 
that OSMAND can find?


Thanks John
--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] How is protect_class used in Canada?

2020-11-16 Thread john whelan
>I am guessing that some or all of the categories on that list under class
7 can simply be deleted.

Have you attempted to contact the original mappers?

We have a few mappers in Canada who have been mapping for more than ten
years.

John

On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
wrote:

> Hello neighbors to the north,
>
> I have been working to clean up and improve documentation on tagging of
> protected areas.  I've found that in many cases the documentation on the
> wiki does not match how tagging is actually done in real life, so I am
> working to make the wiki more accurate and make the information more useful
> to mappers.
>
> The wiki [1] lists seven different categories that are tagged
> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
> them, but the other items in the list looked like generic terms that were
> just tossed in there by the original author ~10 years ago.
>
> So..  what does protect_class=7 tagging mean in Canada?  Does this have
> real meaning or is it a long-ago forgotten convention?  Since this value
> does not render on the default map, it is always paired with something like
> leisure=nature_reserve to force the drawing of an outline.  An overpass
> inspection [2] shows that this value is almost entirely in Quebec.
>
> I am guessing that some or all of the categories on that list under class
> 7 can simply be deleted.  I'd like to understand how this tagging is
> actually used in order to make the documentation useful and/or understand
> what the Canadian consensus for how these values *should* be used.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
> [2] https://overpass-turbo.eu/s/10bS
>
> -Brian (Rhode Island, USA)
> ___
> 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] York Region Building Import

2020-10-06 Thread john whelan
Thanks John

On Tue, Oct 6, 2020, 09:47 Daniel @jfd553  wrote:

> There is a list of available datasets and the proportion of
> existing/imported buildings for each municipality [1].
>
>
>
> Daniel
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings
>
>
>
>
>
> *From:* John Whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Tuesday, October 06, 2020 09:25
> *To:* Daniel @jfd553
> *Cc:* Andrew Deng; Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] York Region Building Import
>
>
>
> Apologies for omitting your name.  I hang my head in shame.
>
> So the final result on the building import was the process and licenses
> are fine but local mappers need to agree with the import being done and if
> they do they can just go ahead but should follow the agreed process?
>
> How many areas does the data exist for that haven't been imported yet?
> Perhaps there might be some interest in importing a few other areas.
>
> Thanks John
>
> Daniel @jfd553 wrote on 2020-10-06 00:00:
>
> Hi all.
>
> The York Region is a component of ODB data import, which has been widely
> discussed and we all agreed that whole import process was acceptable. There
> is then no reason to go back to the import mailing list to do the
> discussion again. Look here [1] for the appropriate import procedure.
>
>
>
> Speaking of buildings... In order to stay active during Covid-19
> lockdowns, I have been working on a Covid-19 personal mapping project since
> mid-April. My objective was to map the buildings in Sherbrooke (ODB only
> providing 5% of the buildings).
>
> After mapping around 30,000 buildings (according to an Overpass Turbo
> query), 80% of my initial goal is achieved. I keep moving forward with
> mapping and updating buildings and related features.
>
>
>
> Best regards
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings
>
>
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com ]
>
> *Sent:* Monday, October 05, 2020 22:55
> *To:* Andrew Deng
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] York Region Building Import
>
>
>
> There are two sources of buildings to import one is Bing the other is the
> stat Canada licensed one.  Both have the correct license for OSM.
>
>
>
> If you are going after the stat can one then there was an import plan
> drawn up for Canada and that is in the wiki.
>
>
>
> I suggest if you use the stat can import plan basically just copy it
> together with the license information or perhaps you can do a sort of
> amendment of it to cover York.  The reason I suggest that is there is an
> import mailing group that gets involved and they tend to ask all sorts of
> questions.  Getting by them has been described as the hardest part of the
> import process.
>
>
>
> The original import was done in Ottawa and we got all the licensing
> permissions sorted out and because Ottawa is fairly small the local group
> formed a consensus that that is what they were happy with and that was the
> basis of that import.
>
>
>
> When we set it up to import across Canada the problem with the stat can
> data was the quality varied from municipality to municipality and there was
> some concerns about if the data should be preprocessed in some way.  Also
> in some areas such as Toronto local mappers wanted to feel more in control.
>
>
>
> I can't recall who came up with the preprocessing but I'm sure James will
> remember.  Pierre I'm almost certain expressed his opinion.  It might be
> worth looking at what they came up with and why.  I do recall that some
> mappers thought the Ottawa building import should have been preprocessed
> but the local mappers were happy with the raw data.
>
>
>
> Cheerio John
>
>
>
> On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca <
> talk-ca@openstreetmap.org> wrote:
>
> Hello,
>
>
>
> I primarily map in York Region, Ontario, and I have noticed that the
> Toronto Building Import has been completed 3 months ago. Therefore, I am
> proposing to open a task on the Task Manager for York Region buildings,
> since having the buildings imported here would be nice. I'm not sure of the
> process on how to do that, which is why I'm emailing this group.
>
>
>
>
>
> --
>
>
>
> Andrew (andrepoiy on OSM)
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> --
>
> Sent from Postbox <https://www.postbox-inc.com>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] York Region Building Import

2020-10-06 Thread John Whelan

Apologies for omitting your name.  I hang my head in shame.

So the final result on the building import was the process and licenses 
are fine but local mappers need to agree with the import being done and 
if they do they can just go ahead but should follow the agreed process?


How many areas does the data exist for that haven't been imported yet? 
Perhaps there might be some interest in importing a few other areas.


Thanks John

Daniel @jfd553 wrote on 2020-10-06 00:00:


Hi all.

The York Region is a component of ODB data import, which has been 
widely discussed and we all agreed that whole import process was 
acceptable. There is then no reason to go back to the import mailing 
list to do the discussion again. Look here [1] for the appropriate 
import procedure.


Speaking of buildings... In order to stay active during Covid-19 
lockdowns, I have been working on a Covid-19 personal mapping project 
since mid-April. My objective was to map the buildings in Sherbrooke 
(ODB only providing 5% of the buildings).


After mapping around 30,000 buildings (according to an Overpass Turbo 
query), 80% of my initial goal is achieved. I keep moving forward with 
mapping and updating buildings and related features.


Best regards

[1] 
https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings


*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Monday, October 05, 2020 22:55
*To:* Andrew Deng
*Cc:* Talk-CA OpenStreetMap
*Subject:* Re: [Talk-ca] York Region Building Import

There are two sources of buildings to import one is Bing the other is 
the stat Canada licensed one.  Both have the correct license for OSM.


If you are going after the stat can one then there was an import plan 
drawn up for Canada and that is in the wiki.


I suggest if you use the stat can import plan basically just copy it 
together with the license information or perhaps you can do a sort of 
amendment of it to cover York.  The reason I suggest that is there is 
an import mailing group that gets involved and they tend to ask all 
sorts of questions.  Getting by them has been described as the hardest 
part of the import process.


The original import was done in Ottawa and we got all the licensing 
permissions sorted out and because Ottawa is fairly small the local 
group formed a consensus that that is what they were happy with and 
that was the basis of that import.


When we set it up to import across Canada the problem with the stat 
can data was the quality varied from municipality to municipality and 
there was some concerns about if the data should be preprocessed in 
some way.  Also in some areas such as Toronto local mappers wanted to 
feel more in control.


I can't recall who came up with the preprocessing but I'm sure James 
will remember.  Pierre I'm almost certain expressed his opinion.  It 
might be worth looking at what they came up with and why.  I do recall 
that some mappers thought the Ottawa building import should have been 
preprocessed but the local mappers were happy with the raw data.


Cheerio John

On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca 
mailto:talk-ca@openstreetmap.org>> wrote:


Hello,

I primarily map in York Region, Ontario, and I have noticed that
the Toronto Building Import has been completed 3 months ago.
Therefore, I am proposing to open a task on the Task Manager for
York Region buildings, since having the buildings imported here
would be nice. I'm not sure of the process on how to do that,
which is why I'm emailing this group.

--

Andrew (andrepoiy on OSM)

___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca



--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] York Region Building Import

2020-10-05 Thread john whelan
There are two sources of buildings to import one is Bing the other is the
stat Canada licensed one.  Both have the correct license for OSM.

If you are going after the stat can one then there was an import plan drawn
up for Canada and that is in the wiki.

I suggest if you use the stat can import plan basically just copy it
together with the license information or perhaps you can do a sort of
amendment of it to cover York.  The reason I suggest that is there is an
import mailing group that gets involved and they tend to ask all sorts of
questions.  Getting by them has been described as the hardest part of the
import process.

The original import was done in Ottawa and we got all the licensing
permissions sorted out and because Ottawa is fairly small the local group
formed a consensus that that is what they were happy with and that was the
basis of that import.

When we set it up to import across Canada the problem with the stat can
data was the quality varied from municipality to municipality and there was
some concerns about if the data should be preprocessed in some way.  Also
in some areas such as Toronto local mappers wanted to feel more in control.

I can't recall who came up with the preprocessing but I'm sure James will
remember.  Pierre I'm almost certain expressed his opinion.  It might be
worth looking at what they came up with and why.  I do recall that some
mappers thought the Ottawa building import should have been preprocessed
but the local mappers were happy with the raw data.

Cheerio John

On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> Hello,
>
> I primarily map in York Region, Ontario, and I have noticed that the
> Toronto Building Import has been completed 3 months ago. Therefore, I am
> proposing to open a task on the Task Manager for York Region buildings,
> since having the buildings imported here would be nice. I'm not sure of the
> process on how to do that, which is why I'm emailing this group.
>
>
> --
>
>
>
> Andrew (andrepoiy on OSM)
>
> ___
> 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: [OSM-talk] Can you recommend good introduction to JOSM for 100% osm newbie?

2020-10-05 Thread john whelan
I think we underestimate new mappers.  JOSM takes a little more time to set
up true enough but once set up new mappers can be quite productive.  I
think it is best if you limit them to adding one or two features at a time
but for adding buildings nothing beats it with the buildings_tool plugin.

The number of misshapped, mistagged, untagged buildings in OSM is testament
to the difficulties they have with other editors.

Highways, I think it is iD that offers many choices of tags but do we
really need rural highways in Africa to be tagged as unlit?


Cheerio John

On Mon, Oct 5, 2020, 06:25 Andy Townsend  wrote:

> On 05/10/2020 08:57, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
>
> On 5. Oct 2020, at 00:58, Michael Booth  
>  wrote:
> Not sure I'd recommend JOSM for a 100% OSM newbie unless there was a specific 
> reason or feature required when editing.
>
>
>
> I would, because they will have to learn from scratch anyway, so why not 
> starting with the most popular (by numbers of edits), most powerful, most 
> versatile, closest to the community consensus and longest standing (i.e. most 
> reliable that it will remain) editor?
>
> Telling potential new contributors that they need to use JOSM to
> contribute to OSM will have two effects:
>
>1. It'll put lots of people off contributing to OSM at all.
>2. It'll cause lots of errors in OSM where people don't understand
>what they're doing do things by accident.
>
> All tools have their strengths and weaknesses and it makes sense to use
> the right tool for the job in each case.  JOSM is great for some things - I
> regularly use 4 different OSM editors on a regular basis and by some
> measure of "most edits" JOSM may well be "the editor that I use most", but
> I wouldn't recommend it to anyone who isn't familiar with the basics in OSM
> at all yet.  People need to find out how "what they see in the real world"
> and "what they see on a map" relate to "what data is actually in OSM" and
> JOSM really isn't good at explaining, or in some cases even representing,
> that.
>
> Best Regards,
>
> Andy
> ___
> 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: [OSM-talk] A Call to Correct Narratives about Geospatial Work in the Philippines

2020-09-04 Thread john whelan
I have noticed that HOT does tend to promote the idea that HOT mapping is
bringing maps to areas that haven't been mapped before.  The emphasis is on
enthusiasm and tapping into the mappers before they move on to something
else.  This approach does get a fair bit of mapping done and the quality
side is improving.

I suspect that mix that in with a journalistic approach that tends to be
cost driven and simplify and the result is what you see.

There are some more serious HOT mappers and as you note quite a few
contributions to OpenStreetMap come from trained professional mappers
working for governments.

I think all we can do is recognise there is a range of contributors to
OpenStreetMap but how you get this recognised I'm not sure.  Talk nicely to
the BBC perhaps and ask them nicely to create a program on the subject?

Create a video?  To get a professional looking video is more complex that
it might sound at first glance.

Cheerio John

On Fri, Sep 4, 2020, 10:08 Eugene Alvin Villar  wrote:

> Hello all,
>
> Last September 1, Amazon Web Services (AWS) released an episode of their
> documentary series Now Go Build which highlighted the work done by the
> Humanitarian OpenStreetMap Team in the Philippines, especially in mapping
> the town of Guagua, in the province of Pampanga.
>
> You can see AWS' video here: https://www.youtube.com/watch?v=hqQwEOaKRas
>
> Several members of the OSM-PH community however have observed that there
> are missing and problematic narratives in the video related to the story it
> tells of geospatial and humanitarian workers in the country.
>
> Therefore, some of us have prepared and released the following statement:
> https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf
>
> Regards,
> Eugene
> ___
> 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: [OSM-talk] Fwd: Re: Roadmap for deprecation of name tags in OSM

2020-08-09 Thread john whelan
I honestly can't see any benefit.  Splitting the data into two places adds
the danger of it getting out of sync.

Standard naming conventions would be nice but defining the standard name is
practically impossible.  Compare taginfo to the map features wiki page.
One problem with map features is what is written is often one person's idea
of what the standard name should be.

And different features really are called difference things in different
countries.  It can be difficult to stretch a "standard" name to cover many
things.

For example in Canada many highways have wide shoulders to dump snow on in
winter.  In summer they are often used by cyclists but they aren't cycle
lanes by any stretch of imagination even though some are paved.

Cheerio John

On Sun, Aug 9, 2020, 15:04 pangoSE  wrote:

> Could you reply with your arguments in favor of the current one2one tag
> model system in the other thread where I listed the benefits as I see them?
>
> E.g. permanent unique ids, talk pages if we want that for every osmid,
> SPARQL support, standardization benefits "riding the current ride in open
> data", scripting support for botmakers, and above all support for
> references and linking interactively to other data sources.
> Bots are very useful e.g. to notify an editor of a possible tagging
> mistake or checking urls of references. Martin could also reference an
> image in Wikimedia commons directly on the statement it relates to.
>
> Unique Qids for every osm object that is decoupled from the underlying
> osmid gives some possibility we don't have today regarding integration with
> e.g. wikidata.
>
> Cheers
>
> Mateusz Konieczny via talk  skrev: (9 augusti
> 2020 20:14:03 CEST)
>>
>> It still fails to provide even a single benefit over the current
>> situation.
>>
>> Aug 9, 2020, 20:11 by pang...@riseup.net:
>>
>>
>>
>>
>>  Originalmeddelande 
>> Från: pangoSE
>> Skickat: 9 augusti 2020 15:40:41 CEST
>> Till: talk@openstreetmap.org
>> Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
>>
>> This is another good reason to abandon this suggestion in favor of our
>> own wikibase instance.
>>
>> Philip Barnes  skrev: (9 augusti 2020 15:12:21
>> CEST)
>> >On Sun, 2020-08-09 at 09:04 -0400, James wrote:
>>
>> Not to mention if someone wants to add a name for a new item/object,
>> does the user need to create a wikidata item on top of it? Will the
>> editor do it automatically? How does it pick the right one? Does it
>> offer a list to the user? This is going to make osm a massive turn
>> off to new contributors on the steep learning curve(which is already
>> pretty high) to contributing to osm.
>> This whole idea is really terrible and could just be offered as a
>> post-processed data set: wikidata? use that instead of name tag.
>>
>> >This leads me to a fairly fundamental question, what if a mapper does
>> >not want to be associated with wikidata and refuses to sign up?
>> >Phil (trigpoint)
>>
>> --
>> Skickat från min Android-enhet med k9.
>>
>> ___
>> 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: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Thread john whelan
If Air is proprietary and an Adobe product I strongly suggest avoiding it
purely from a security point of view.  Adobe does not have a good
reputation in the security world.  Comments certainly have been made about
Flash.

I don't think we should be encouraging the installation of software that
could cause problems for our mappers.

I accept that for many who know potlatch well there is a cost of learning
something new and many are experienced editors who we'd like to see
continue but there are tradeoffs and I think security of the software we
are asking people to install should be taken into account.

Cheerio John

On Sun, Aug 2, 2020, 08:54 pangoSE  wrote:

> Is this the platform you are targeting?
> https://en.m.wikipedia.org/wiki/Adobe_AIR
>
> Its proprietary which makes it prone to the same fate as Flash Player. Why
> even consider such a move?
>
> I never use nonfree software like flash so I never tried P2. What is so
> special about it? Is there something hindering adding that specialness (as
> a plugin perhaps) to JOSM?
>
> The JOSM devs seem very helpful, supporting and have a friendly culture.
>
> I suggest letting this code die as it lures people to install nonfree and
> therefore dangerous software. Alternatively that you team up with your 20
> mio edits-peers and port the code to something that does not require
> proprietary software.
>
> You did not present a single usecase that is not covered already by one of
> the other free software editors so I'm guessing you will have a hard time
> convincing your peers to team up around yet another editor, but I might be
> wrong.
>
> I don't care about your ROI arguments because they are based on the not
> outspoken premise that economics of software development is more important
> when making decisions than freedom, which is false IMO.
> If you had compared 2 free software projects like iD and JOSM that run
> without any proprietary code, then it might have been relevant.
>
> I suggest declining support of any software project that is or requires
> proprietary software to run.
>
> Cheers
> pangoSE
> PS I use 4 different editors to edit in the database: JOSM, OsmAnd,
> StreetComplete and rarely iD.
>
>
> Richard Fairhurst  skrev: (2 augusti 2020 10:28:22
> CEST)
>>
>> Skyler Hawthorne wrote:
>> > Sorry if this sounds harsh, but I think using any funds at all to
>> > continue support for a tool that 1% of editors use would be wasteful.
>> > Flash is, for all intents and purposes, a dead technology. This
>> > money is better spent on other uses.
>>
>> The entire point is to move away from a dead technology (Flash Player) to
>> a supported one (AIR).
>>
>> On the percentage stat, it's worth bearing in mind that the P2 project is
>> by a long chalk the smallest sum (€2500) of the three that OSMF is
>> proposing here. As a point of comparison, iD was initially developed with a
>> $575,000 grant from the Knight Foundation in 2012, so roughly $646,000 now.
>> Very conservatively estimating the cost of employing 1-2 developers to code
>> on iD since then, you get a development cost of roughly €0.004 per (2020)
>> changeset for iD vs $0.0002 for P2, which is kind of fun.
>>
>> (I'm actually pleasantly surprised that P2 still has so many changesets -
>> 20 million last year, and I'm guessing high teens this year - given how
>> difficult it is to get Flash Player running in most browsers these days.
>> That suggests that P2's users are using it because they want to do so, not
>> because they are magically unaware of the existence of other editors. I
>> suspect if you could find another way of getting 20 million edits for €2500
>> then we would snap your hand off.)
>>
>> Looking forward, and continuing the theme of ROI, the other benefit of
>> the project is that it enables development work to continue on P2. The
>> reason I have bid for funding for this, for the first time in 14 years of
>> developing editors for OpenStreetMap, is that it will take a solid chunk of
>> sustained work to do the AIR conversion and a bunch of other stuff I
>> believe will make P2 more sustainable into the future, and there is a hard
>> deadline for that sustained work (i.e. Flash Player switch-off at the end
>> of the year). It's not a project that can just be done in evenings here and
>> there. That enables further, unfunded developments in the future, and in
>> turn I hope the tradition of other editors taking inspiration from P2 can
>> continue - it's not for nothing that JOSM has a Potlatch 2 style and a
>> "Potlatch mode" for editing.
>>
>> But you are, of course, welcome to develop and put forward a project to
>> OSMF which you believe will have more bang for the buck. "Other uses" is
>> easy to type but doesn't actually mean anything until you identify what
>> those uses are, and crucially, find someone who is prepared to do them.
>>
>> Richard
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> 

Re: [OSM-talk] [Osmf-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-01 Thread John Whelan
Working on old code is always difficult. IBM got to the point of 
removing a bug to their mainframe operating system on average introduced 
a new bug.


Then you get into the testing side of things.

The flash side of potlatch is one that given the number of editors using 
it and alternatives available to them today may not be a good return on 
investment and I think that should be weighed up.


Nomination I think is essential and if it can be expanded so much the 
better.


osm2pgsql is not something I have direct experience with but I suspect 
it is one of the infrastructure things that many other things depend on.


The learning curve on old code is steep and if you have someone who 
knows the code then I think use them if you possibly can.  I've seen a 
consultant been brought in to make a change and on half way through the 
second day one of the programmers walked up to him and asked him what 
the change was.  The consultant was pointed to the line of code that 
needed to be altered and it took a few seconds to make the change. The 
consultant was trying to understand what the entire program did before 
making any changes in case it had an impact which was the correct thing 
for the consultant to do but experience with the software makes things 
much faster.


Oh and I've seen someone say we can do that in half the time and half 
the cost.  Problem was they didn't understand the problems involved or 
what needed to be done.  They were fired a week later when it didn't 
work but that didn't solve the program problem.


Have fun

Cheerio John

Frederik Ramm wrote on 2020-08-01 19:40:

Hi,

nice to see you rescue a few worthwhile things that have fallen through
the cracks of the Microgrant programme.


During the Microgrants process, there were proposals that didn’t make
it, but would together be a good pilot for a “OSM infrastructure”
process,

Are you planning to take the funds for these projects out of the
"Pineapple Grant" money, or out of the regular budget?


The OSMF Board wants to fund a limited number of projects proposed by
trusted long-term volunteers whose work we know and enjoy.

I think that "trusted long-term volunteers" is key here, and somewhat of
a weak point at the same time.

I notice that all three proposals are very short on hard deliverables;
what they mostly promise is working a certain number of hours on a
certain thing but there is no guarantee that, or to what extent, the
thing is going to be achieved. Richard's proposal is the clearest here
("The result will be a version of Potlatch 2 that can be run on Mac and
Windows laptops"), whereas Jochen and Sarah only commit to working on
something, not to actually achieving it. This means we'll pay them no
matter what.

Now this is all fine because we have reason to believe that every one of
the three proposals will be a good investment and even if a goal could
not be achieved, the money would at least land with people who have done
a lot of volunteer stuff for OSM in the past. But the criteria are fuzzy
- why do we trust these three people that if we give them money to work
on something it will be worth it? Assume someone came along saying wait
a minute, I can do the same for half the money! And then we would say,
err, umm, sorry, no, we don't trust you in the same way we trust these
"trusted long-term volunteers".

Looking forward, it might become necessary to define deliverables more
clearly and make payment conditional on results having been achieved,
rather on time having been spent. But if you're lucky...


In the long term, we want to re-activate the Engineering Working Group
(EWG) by making it a place for decision making, project guidance and
budget management for such projects.

... the EWG can take over that job ;)

Bye
Frederik



--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Heresy - pure discussion

2020-07-25 Thread John Whelan
Looking at it from a TRA (Threat Risk Assessment) point of view 
OpenStreetMap is not totally dependent on one central database being up 
and working.


The primary database is fed by edits but if the database happens to get 
encrypted by Malware the backup and copies are still there.  The tiles 
on the tile server will still display, OSMAND will still work etc.


We strongly suspect that we are not running pure ISO standard SQL, which 
is fine but that does mean we need to take into account other linked 
databases so it would not just be the cost of the central database but 
many other servers and databases that would need to align and that is 
not trivial.  Some other users will have budgets and capacity to move 
others will not.  There is a lot of documentation tied back to the 
existing system which would need to be looked over.  Change management 
is not always simple.


For good database performance we need memory and lots of it so that 
rules out playing with SQL server express.


My concern that we weren't exactly mainstream with our database size has 
been reassured that there are other databases running on the same 
software that are larger.


Since we deal with a large number of new mappers who do odd things I get 
the impression that our procedures are robust and to be honest quite a 
lot of security is good procedures.


So thank you for your inputs, especially those who raised or addressed 
specific issues.


Cheerio John

Mateusz Konieczny via talk wrote on 2020-07-25 08:07:

And database size limit is just a start :)

It is artificially limited to 1G of RAM. I am curious how long planet 
import

with 1GB of RAM would run :)

Jul 25, 2020, 13:31 by jwhelan0...@gmail.com:

And as we start to fill the database with buildings even those
might not fit.

Thanks John

On Sat, Jul 25, 2020, 05:19 Hartmut Holzgraefe mailto:hart...@php.net>> wrote:

On 24.07.20 23:55, john whelan wrote:
> Microsoft SQL Server Express is a free limited version of
SQL server
> that may well do for many users.

reading express edition limitations I see:

* Maximum relational database size: 10GB

That would only be enough for the smallest of OSM regional
extracts ...

-- 
hartmut


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




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


--
Sent from Postbox <https://www.postbox-inc.com>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Heresy - pure discussion

2020-07-25 Thread john whelan
And as we start to fill the database with buildings even those might not
fit.

Thanks John

On Sat, Jul 25, 2020, 05:19 Hartmut Holzgraefe  wrote:

> On 24.07.20 23:55, john whelan wrote:
> > Microsoft SQL Server Express is a free limited version of SQL server
> > that may well do for many users.
>
> reading express edition limitations I see:
>
> * Maximum relational database size: 10GB
>
> That would only be enough for the smallest of OSM regional extracts ...
>
> --
> hartmut
>
> ___
> 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: [OSM-talk] Heresy - pure discussion

2020-07-24 Thread John Whelan

Thank you Hartmut,

my expertise is not in GIS databases so this is helpful to know.  My 
experience is much more to do with straight SQL databases doing none GIS 
work on a variety of platforms.


Cheerio John

Hartmut Holzgraefe wrote on 2020-07-24 18:49:

On 25.07.20 00:16, Alexandre Oliveira wrote:

Having said that the main advantage of SQL is
it is a standard so you should be able to connect practically 
anything to

it.

That's not entirely true. SQL is a language but every database
implements its own dialect, i.e., some query keywords implemented in
MSSQL might not be available in MySQL/MariaDB and vice-versa.




SQL is a "standard" only in so far as developers are somewhat
interchangeable between products.

There is nothing that prevents RDBMS implementations from adding
features on top of the standard, and most of the standard features
are optional anyway.

E.g. the actual ISO SQL standard for stored procedures is only really 
implemented by IBM/DB2, MySQL and MariaDB, while all other RDBMS 
products implement their own procedure languages (and I can't even

blame them, as the ISO SQL standard syntax feels as if it got
stuck in the old BASIC days).

The key question though would be: is MS SQL Server GIS support
on par with PostGIS?

My impression so far was that it provides just a little bit more
than what the OGC 1.1 standard requires.

That would put it in the same league as MySQL and MariaDB, maybe
slightly ahead, but very far below what PostGIS provides.

(Disclaimer: I'm working for MariaDB as a support engineer, and
have been working for MySQL before, so I may a little bit biased.
But even I would always recommend the PostgreSQL / PostGIS combo
over MariaDB for all but the most basic GIS applications)



--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Heresy - pure discussion

2020-07-24 Thread john whelan
You need to define the requirements and if having open source software is a
top priority that's fine.

If reliability and security are critical then you have to start balancing
things out.

In general UNIX based solutions do not have the same tools available in
Windows but with a skilled administrator they can be made reasonably
reliable and secure but a higher level of skill is required in the UNIX
environment.  Skilled administrator time from volunteers is not expensive
having said that we should be asking them to do more work than we could?

The 300 users and 600 accounts was actually on a Microsoft SQL server where
each database user was given their own account and password.   No record of
who was given which account was kept and over the years people came and
left.  I agree the admins were at fault but over the years there had been a
number of admins some had more expertise than others and to an outsider
knowing which knew what they were doing and which were basically bluffing
is not always easy.  We had probably fifty database administrators besides
my team all doing their own thing.  On the Microsoft SQL databases where we
used Windows operating system groups if someone left they were removed from
the group and we could check with their admin if they were part of the
section or not.

Microsoft SQL Server Express is a free limited version of SQL server that
may well do for many users.  Having said that the main advantage of SQL is
it is a standard so you should be able to connect practically anything to
it.

For development Microsoft visual studio is normally recognised as the gold
standard for development environments and remember Github is now owned by
Microsoft.

Cheerio John

On Fri, Jul 24, 2020, 17:03 Yves  wrote:

> But face it, philosophy is now also part of the discussion. And that's
> important.
> Yves
>
> Le 24 juillet 2020 20:50:22 GMT+02:00, john whelan 
> a écrit :
>>
>> If the database was smaller and less infrastructure was reliant on it
>> working I would agree with you that philosophically open source software
>> makes a lot of sense.
>>
>> However your argument is philosophical rather than logical.
>>
>> Note I'm merely requesting that the idea be examined.  I am not saying I
>> know what is best and all the things that need to be considered.
>>
>> Cheerio John
>>
>> On Fri, Jul 24, 2020, 14:35 Yves  wrote:
>>
>>> You're probably have some very good points when it comes to database
>>> management, but running an open map on open source software makes a lot of
>>> sense.
>>>
>>> Yves
>>>
>>> Le 24 juillet 2020 20:11:46 GMT+02:00, john whelan <
>>> jwhelan0...@gmail.com> a écrit :
>>>>
>>>> All this talk about databases and servers and sysadmins makes me wonder
>>>> if we should reconsider our choice of operating systems and databases.
>>>>
>>>> At one time in the past I ran a Database support group that covered
>>>> Sybase, Oracle, Microsoft SQL server, ingres and half a dozen other
>>>> database systems.
>>>>
>>>> The UNIX side, some twenty or so servers ran software that in theory
>>>> monitored the databases.  In practise it never really was upto date.
>>>> Microsoft also had a very nice monitoring tool that monitored and suggested
>>>> solutions.  I've dropped an example report below.
>>>>
>>>> We ran probably fifty SQL server database servers and I spent quite a
>>>> lot of time maxing the memory on a server then consolidating servers.
>>>> Towards the end we had far more data running on SQL server than we did on
>>>> the UNIX side.  The servers were cheaper for the same performance for a
>>>> start.
>>>>
>>>> Many of the UNIX based servers had default passwords set which made
>>>> security a problem.  Fortunately they were protected by an air gap from the
>>>> Internet.
>>>>
>>>> We had an IBM mainframe in the mix with an old database on it.  The
>>>> programmers gradually retired.  I was lucky and identified another
>>>> government department that was switching away from it and we managed to
>>>> grab a handful of programmers etc from them.  Then a couple of years later
>>>> that DBA retired.  You need to think of the future.  Will I be able to get
>>>> knowledgeable staff if I need to?  We had to pay the company to run a
>>>> special course in Ottawa and that was not cheap by the time we put the
>>>> trainer up in a hotel and paid his airfare from the states.
>>>>
>>>> Initially the Microsoft side suffere

Re: [OSM-talk] Heresy - pure discussion

2020-07-24 Thread john whelan
If the database was smaller and less infrastructure was reliant on it
working I would agree with you that philosophically open source software
makes a lot of sense.

However your argument is philosophical rather than logical.

Note I'm merely requesting that the idea be examined.  I am not saying I
know what is best and all the things that need to be considered.

Cheerio John

On Fri, Jul 24, 2020, 14:35 Yves  wrote:

> You're probably have some very good points when it comes to database
> management, but running an open map on open source software makes a lot of
> sense.
>
> Yves
>
> Le 24 juillet 2020 20:11:46 GMT+02:00, john whelan 
> a écrit :
>>
>> All this talk about databases and servers and sysadmins makes me wonder
>> if we should reconsider our choice of operating systems and databases.
>>
>> At one time in the past I ran a Database support group that covered
>> Sybase, Oracle, Microsoft SQL server, ingres and half a dozen other
>> database systems.
>>
>> The UNIX side, some twenty or so servers ran software that in theory
>> monitored the databases.  In practise it never really was upto date.
>> Microsoft also had a very nice monitoring tool that monitored and suggested
>> solutions.  I've dropped an example report below.
>>
>> We ran probably fifty SQL server database servers and I spent quite a lot
>> of time maxing the memory on a server then consolidating servers.  Towards
>> the end we had far more data running on SQL server than we did on the UNIX
>> side.  The servers were cheaper for the same performance for a start.
>>
>> Many of the UNIX based servers had default passwords set which made
>> security a problem.  Fortunately they were protected by an air gap from the
>> Internet.
>>
>> We had an IBM mainframe in the mix with an old database on it.  The
>> programmers gradually retired.  I was lucky and identified another
>> government department that was switching away from it and we managed to
>> grab a handful of programmers etc from them.  Then a couple of years later
>> that DBA retired.  You need to think of the future.  Will I be able to get
>> knowledgeable staff if I need to?  We had to pay the company to run a
>> special course in Ottawa and that was not cheap by the time we put the
>> trainer up in a hotel and paid his airfare from the states.
>>
>> Initially the Microsoft side suffered from lack of security but they
>> hardened the operating system and SQL server to a point where it was the
>> most secure combination.  Microsoft SQL server was originally Sybase but
>> got completely rewritten over time.
>>
>> On the support side my staff found that once we had set the permissions
>> to an operating system group we just had to add people to the group.  For
>> other databases each person had to be given permissions individually which
>> made for finger problems.  The classic was one secure database that was
>> supposed to be accessed operationally by 300 people. The problem was there
>> were 600 accounts and no one knew which ones were needed or which could be
>> deleted to reduce the surface area for attack.
>>
>> The integrated Microsoft monitoring system made reliability much better.
>> There were far fewer problems on the Microsoft SQL side than on the UNIX /
>> other database side and they were easier to fix.  One of my less expert
>> database admins was shocked by the ease of which he caught the problem and
>> corrected it by himself after an alert.  It gave him a bit of confidence as
>> well.
>>
>> We changed to PostgreSQL in 2009.  The size of the database was much
>> smaller then.
>>
>> One thing we noticed was on the database tuning side.  SQL server worked
>> better if you just left it alone and didn't try to tune it.  It would check
>> what was in memory rather than go out to the disk drives and that made a
>> big difference to performance.  We measure disk access in milliseconds and
>> memory access in nanoseconds.  One is ten thousand times smaller than the
>> other.
>>
>> On the reliability side there is a set of guidelines that are basically
>> common sense.  I forget the formal (ISO?) name but many organisations have
>> seen considerable savings in money and in reliability by using them.  I met
>> the English guy who originated them at a Microsoft presentation.  They can
>> be applied to any environment.
>>
>> I think we either run the largest PostgreSQL database there is or it is
>> close to it.  From a reliability point of view my professional hat says
>> this is not where you want to be. You want to be more mainstrea

[OSM-talk] Heresy - pure discussion

2020-07-24 Thread john whelan
All this talk about databases and servers and sysadmins makes me wonder if
we should reconsider our choice of operating systems and databases.

At one time in the past I ran a Database support group that covered Sybase,
Oracle, Microsoft SQL server, ingres and half a dozen other database
systems.

The UNIX side, some twenty or so servers ran software that in theory
monitored the databases.  In practise it never really was upto date.
Microsoft also had a very nice monitoring tool that monitored and suggested
solutions.  I've dropped an example report below.

We ran probably fifty SQL server database servers and I spent quite a lot
of time maxing the memory on a server then consolidating servers.  Towards
the end we had far more data running on SQL server than we did on the UNIX
side.  The servers were cheaper for the same performance for a start.

Many of the UNIX based servers had default passwords set which made
security a problem.  Fortunately they were protected by an air gap from the
Internet.

We had an IBM mainframe in the mix with an old database on it.  The
programmers gradually retired.  I was lucky and identified another
government department that was switching away from it and we managed to
grab a handful of programmers etc from them.  Then a couple of years later
that DBA retired.  You need to think of the future.  Will I be able to get
knowledgeable staff if I need to?  We had to pay the company to run a
special course in Ottawa and that was not cheap by the time we put the
trainer up in a hotel and paid his airfare from the states.

Initially the Microsoft side suffered from lack of security but they
hardened the operating system and SQL server to a point where it was the
most secure combination.  Microsoft SQL server was originally Sybase but
got completely rewritten over time.

On the support side my staff found that once we had set the permissions to
an operating system group we just had to add people to the group.  For
other databases each person had to be given permissions individually which
made for finger problems.  The classic was one secure database that was
supposed to be accessed operationally by 300 people. The problem was there
were 600 accounts and no one knew which ones were needed or which could be
deleted to reduce the surface area for attack.

The integrated Microsoft monitoring system made reliability much better.
There were far fewer problems on the Microsoft SQL side than on the UNIX /
other database side and they were easier to fix.  One of my less expert
database admins was shocked by the ease of which he caught the problem and
corrected it by himself after an alert.  It gave him a bit of confidence as
well.

We changed to PostgreSQL in 2009.  The size of the database was much
smaller then.

One thing we noticed was on the database tuning side.  SQL server worked
better if you just left it alone and didn't try to tune it.  It would check
what was in memory rather than go out to the disk drives and that made a
big difference to performance.  We measure disk access in milliseconds and
memory access in nanoseconds.  One is ten thousand times smaller than the
other.

On the reliability side there is a set of guidelines that are basically
common sense.  I forget the formal (ISO?) name but many organisations have
seen considerable savings in money and in reliability by using them.  I met
the English guy who originated them at a Microsoft presentation.  They can
be applied to any environment.

I think we either run the largest PostgreSQL database there is or it is
close to it.  From a reliability point of view my professional hat says
this is not where you want to be. You want to be more mainstream with
someone else being on the bleeding edge.

So the heresy would be look at the implications of changing to Microsoft
SQL server in the cloud.  There is lots of documentation and given that
Microsoft has worked closely with us in the past the cost might not be too
bad.  I do understand that we have a large investment in our current set up
both as an organisation and personally and many will consider this as
heresy but now is probably the time to think about it.

Cheerio John









Your message to rolland.desroc...@motioncares.ca couldn't be delivered.
Rolland.desrocher wasn't found at motioncares.ca.
jwhelan0112 Office 365 Rolland.desrocher
*Action Required*
Recipient





Unknown To address


How to Fix It
The address may be misspelled or may not exist. Try one or more of the
following:

   - Send the message again following these steps: In Outlook, open this
   non-delivery report (NDR) and choose *Send Again* from the Report
   ribbon. In Outlook on the web, select this NDR, then select the link "*To
   send this message again, click here.*" Then delete and retype the entire
   recipient address. If prompted with an Auto-Complete List suggestion don't
   select it. After typing the complete address, click *Send*.
   - Contact the recipient (by phone, for example) to check 

Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

2020-07-17 Thread john whelan
What Jarek says makes sense to me.  I suspect many of the map users don't
live where the use the map.

Having said that could we come up with something that could be applied
across Canada or is that too much to ask for?

Thanks John

On Thu, Jul 16, 2020, 22:39 Jarek Piórkowski  wrote:

> On Thu, 16 Jul 2020 at 11:30, Andrew Deng via Talk-ca
>  wrote:
> > Hello, I believe Yonge Street in Toronto and York Region (Regional Road
> 1) should be tagged as highway=primary rather than highway=secondary as it
> is tagged now.
> > Here are some reasons I believe why:
> > 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
> > 2) It is a major thoroughfare throughout the route. In Toronto, the
> Yonge subway follows it and in York Region, Viva bus lanes are being built.
> It also connects to Bradford in the north.> 3) It was a former Ontario
> King's Highway - Highway 11. Some other former King's Highways in the
> Toronto/York area are tagged as highway=primary, such as Highway 27,
> Highway 7, and Highway 48.
>
> Hi Andrew, hi mailing list,
>
> I've been thinking about this for a while. Thanks for bringing this up!
>
> I'd like to contribute to a wider discussion about tagging primary in
> Ontario, particularly in urban and suburban areas. I think we should
> use it more - here's why.
>
> I've been unhappy for a while with the tagging guidelines for Ontario
> roads. The primary/secondary/tertiary OSM scheme originated in the UK,
> where basically all "A-roads" are primary (or trunk) and all "B-roads"
> are secondary. This is a UK-wide scheme and a crucial point is that
> there are still A-roads in busy urban areas. For example what is by
> GTA standards a narrow street in inner city like
> https://osm.org/way/327282307 (one-way, 1 or at most 2 lanes) is
> primary because it's an A road. [1] Many other regions in Europe also
> use primary for urban thoroughfares with frequent cross streets.
>
> For a long time, the Canadian tagging guidelines were a very close
> copy of the UK scheme - check out Danny's wiki edit in May 2019 [2]
> that removed very UK-like references to "C roads" (a UK
> classification) and "a suburb" ("An example would be the main roads
> within the suburb to get to the local primary school", "A
> highway=residential road which is used for accessing or moving between
> private residential properties (homes).  Otherwise called a
> 'suburb'."), and removed a statement that primary, secondary, and
> tertiary roads are "all maintained by the provincial governments, with
> provincial jurisdiction."
>
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
> still specifies that in Canada, a highway=primary is a "Provincial
> primary highway that does not meet freeway standards". That might work
> in BC, where there are provincial highways in downtown Vancouver, but
> it doesn't work in Ontario. BC Highway 99 through downtown Vancouver
> is tagged as trunk, and it is no wider than Yonge through York Region
> tagged as secondary.
>
> Historically, in Ontario, the maintenance and jurisdiction of a road
> has more to do with whether a lower-level government could be
> strong-armed into accepting ownership in the 1990s than with its
> actual role in the road network. Ontario government downloaded the
> roads it could onto the regions and cities, but of course the volume
> of traffic or significance of the road doesn't change just because we
> enter a somewhat-built-up area (or it increases). There's some good
> examples along Highway 7 entering east Kitchener and east Guelph.
> Highways 8 and 24 entering south Cambridge are more examples - it's
> just a cut at point of jurisdiction change, it's got nothing to do
> with the actual road or its use.
>
> As a result, we don't really show the main roads in Ontario cities. We
> mostly jump from a freeway straight to secondary, and most exceptions
> are recent changes.
>
> To an extent a grid system, which most Ontario cities use, does of
> course consist of a number of fairly equal arterials, but natural
> obstacles often get in the way, and so in Toronto/GTA some arterials
> are more equal than others. Is every grid street really the same rank?
> When everything is secondary, what really is secondary?
>
> To give some examples, in Toronto Lake Shore Blvd is clearly a busier
> road and can carry more inter-local traffic than Church or Yonge
> downtown, yet currently they're all secondary. Adelaide and Richmond
> are the designated through corridors - consider especially their
> direct connection to the DVP. Given the choice, you should be driving
> on Adelaide/Richmond, not on Queen - they are designed for this. Yet
> again, Queen, Adelaide, and Richmond are currently all secondary.
>
> Until last year, York Region's Highway 7 was being indicated the same
> secondary as Dundas Street next to Dundas Square (because after all,
> Hwy 7 was downloaded). They are 

Re: [OSM-talk] Paid mapping

2020-06-22 Thread John Whelan
I've seen a lot of poor mapping get replicated in this way by newcomers 
copying the tags.


Cheerio John

Mike Thompson wrote on 2020-06-22 8:25 PM:



On Mon, Jun 22, 2020 at 4:12 PM Mateusz Konieczny via talk 
mailto:talk@openstreetmap.org>> wrote:


Jun 23, 2020, 00:07 by miketh...@gmail.com
:

"except for the preceding, we follow OSM community norms."

This should be enough to ban of all their mapping accounts until
changing their plan
(I assume that they either backtracked that or stopped editing)

They said that they were going to do some additional training for 
their staff.  They did give some indication they would make some 
changes, but I didn't follow up. Part of the problem is that another, 
non local, mapper got really enthusiastic a couple of years ago about 
changing all unpaved roads to highway=track.  Amazon Logistics people 
see this, and if they are adding a road, they perhaps compare it to 
the existing content nearby, and try to mimic that tagging.


Mike


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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Paid mapping

2020-06-22 Thread John Whelan
> In case of noticing low quality paid mapping - please, at least leave 
a changeset comment.


I think this is a sensible approach that I'll use in future rather than 
leave an email.


On the comments about the classification we are talking specifically 
about Africa where it is much more difficult to judge the importance of 
a highway from imagery.


/Pierre Béland /came up with a classification scheme in partnership with 
many players. /


/https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

It has stood the test of time and is normally accepted as the tagging 
standard for highways in Africa.


Many Thanks

Cheerio John

Mateusz Konieczny via talk wrote on 2020-06-22 5:16 PM:


In case of noticing low quality paid mapping - please, at least leave 
a changeset comment.



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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Paid mapping

2020-06-22 Thread john whelan
The ones that stood out were highways that connected settlements to other
settlements on the map.  These had been changed from highway unclassified
surface unpaved to highway=track by a mapper with Apple connections.

They seemed to have retagged a fair number and I don't honestly recall
exactly where they where.  I seem to recall sending an email to the mapper
concerned pointing towards the Africian highway Wiki and assumed that was
the end of the tale.

Today I was looking at a very remote hamlet and was surprised to see it was
connected by a highway=tertiary that terminated in the hamlet.  I'm not
saying it was incorrectly labelled but being curious I had a look at the
history.  If it has been mapped by someone who only mapped twice on a HOT
project that's one thing but this highway had been tagged unclassified then
retagged to tertiary by a mapper who maps for Apple according to his OSM
page and had some 6,000 edits to their name.  It actually says on the
highway from Bing not local knowledge.

When I see two different Apple mappers whom I assume are paid mappers
essentially retagging things rather than mapping new things it raises the
question in my mind are they doing this to improve the map in some way or
are they measured by how many highways have their tag on them?

If it is the latter then a different metric for paid mappers might get more
useful results in the map.

A conventional OSM mapper normally maps to add detail or correct glaring
errors in the map.  A paid mapper might not have the same point of view.

I know I'm cynical and I'm not even sure there is much that can be done
about it.

Cheerio John

On Mon, Jun 22, 2020, 16:12 Joseph Eisenberg 
wrote:

> Please clarify: are the Apple mappers 1) changing the ways to
> highway=track, or 2) changing ways that are currently highway=track to
> something else?
>
> I would support #2 in any case where the way connects settlements, since
> we have always defined highway=track as a way that is used for agriculture,
> forestry etc., not for travel between settlements.
>
> – Joseph Eisenberg
>
> On Mon, Jun 22, 2020 at 11:17 AM John Whelan 
> wrote:
>
>> I've noticed a number of highways being changed in Africa from
>> unclassified to track and from unclassified to tertiary.The ones I've
>> noticed are Apple mappers usually with the comment of from Bing and often
>> the highways connect settlements so should be a minimum of unclassified or
>> path but not track.
>>
>> African highway wiki  says it is difficult to classify highways without
>> local knowledge above unclassified.  Track is fairly easy it doesn't
>> connect settlements according to the wiki.
>>
>> Do I get the impression we are talking targets here?  The paid mappers
>> have to do so many edits to meet their targets and changing the
>> classification using Bing is easier than adding to the map?
>>
>> Do we care?  Is it is just something to be aware of.
>>
>> Thoughts?
>>
>> Thanks
>>
>> Cheerio John
>> --
>> Sent from Postbox <https://www.postbox-inc.com>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] Paid mapping

2020-06-22 Thread John Whelan
I've noticed a number of highways being changed in Africa from 
unclassified to track and from unclassified to tertiary.    The ones 
I've noticed are Apple mappers usually with the comment of from Bing and 
often the highways connect settlements so should be a minimum of 
unclassified or path but not track.


African highway wiki  says it is difficult to classify highways without 
local knowledge above unclassified.  Track is fairly easy it doesn't 
connect settlements according to the wiki.


Do I get the impression we are talking targets here?  The paid mappers 
have to do so many edits to meet their targets and changing the 
classification using Bing is easier than adding to the map?


Do we care?  Is it is just something to be aware of.

Thoughts?

Thanks

Cheerio John
--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-ca] WikiProject Canada Post - franchise assessment

2020-06-16 Thread john whelan
I think you can use it to see where to look.

If there is only one building and you can see a Canada Post logo
floating around I think it is fair game.

Canada Post is part of federal government so there is some sort of
commitment to Open Data floating around under the Federal government's open
data initiative.

Cheerio John

On Tue, Jun 16, 2020, 09:10 Justin Tracey  wrote:

> Is it legal to import that data from the Canada Post site?
>
>  - Justin
>
> On Tue, Jun 16, 2020 at 8:04 AM David Nelson via Talk-ca <
> talk-ca@openstreetmap.org> wrote:
>
>> I have just finished assessing which post offices in Canada among those
>> we have not yet added to OSM are franchises, and which of those franchise
>> outlets' parent businesses already appear in our database.  Those such
>> locations are now marked in pale red on the project's spreadsheets.  The
>> node for each such post office location just has to be positioned right
>> next to its respective parent business.  You can determine what each parent
>> business is by looking on Canada Post’s own website, or by doing a simple
>> web search for the postal code of each such outlet.  With this, we are in a
>> position to immediately add nearly 700 more Canada Post outlets across the
>> country to OSM.  This would bring the progress of this project to a
>> completion measure of just under 48 percent.
>>
>>
>>
>> - David E. Nelson
>>
>> 
>> ___
>> 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] Missing maps in Canada from weeklyosm

2020-04-19 Thread John Whelan
Which sort of ties into the building import side of things as there was 
mention at the start of the project that for many remote communities the 
building data would be valuable.


https://www.missingmaps.org/blog/2020/03/31/a-year-of-blogs/

To me I think missing maps implies mapathons and possible data quality 
issues.


Would it be worth while doing the remote communities with Microsoft 
building data or some such?


Thoughts?

Thanks

Cheerio John






___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

2020-04-03 Thread john whelan
One of the nice things about the disabled community is we get a fair amount
of data either from them or by people supporting them.  As Clifford
mentioned this sort of thing is useful to them and as I grow older this
sort of information is unfortunately getting more useful to myself.

Universities can be useful as well although the students do tend to refine
the detail on highways etc close the them.  In Ottawa a foot bridge I
orginally mapped near the University of Ottawa  has been updated about
thirty times now.  On a personal note the building import in Ottawa came
from a file that was identified by a University lecturer so Universities
can be useful.

When I look at the map I wonder about the level of detail we have
sometimes.  Do we really need to know that the surface is asphalt rather
than paved?

Personally I'd rather see the data included.

Cheerio John

On Fri, Apr 3, 2020, 4:26 PM Martin Chalifoux via Talk-ca, <
talk-ca@openstreetmap.org> wrote:

> Nate, when reading this and other comments I try to figure who puts those
> sidewalks in and to the benefit of what users. From what I can see it is
> being done by university groups essentially, not the community. The
> beneficiaries are organizations that funds those groups with strings
> attached, essentially buying a service. The OSM mass of end-users is not it
> appears the beneficiary but rather a very small group of people. I thus ask
> very honestly are the universities hijacking OSM to execute their research
> projects just because it is there, free and easily usable ? Are OSM users
> ever a concern ? With regards to this specific sidewalk mapping effort I
> really have a hard time figuring how a mainstream OSM user, through the
> site or a mobile app, benefits in any way from this added layer or
> complexity. I tend to think to the contrary is makes the map overly
> complex, add information nobody will ever care about, render the experience
> cumbersome, that with no tangible gain. If that was the case I don’t think
> that would be right.
>
> I don’t mean this to be inflammatory but just an honest questioning.
>
> On Apr 3, 2020, at 15:14, Nate Wessel  wrote:
>
> I used to be opposed to sidewalk mapping, and I still think it is often
> done poorly. I've changed my mind in the last year or two though. When I
> first moved into my current neighborhood and started mapping the area, I
> hated at all the poorly drawn sidewalks. They weren't well aligned, they
> didn't do anything to indicate crossings, and they were far from complete.
> For a while I was temped to delete the lot of them, but instead worked to
> gradually fix them up, noted marked or signalized crossings, added in
> traffic islands, pedestrian barriers etc.
>
> Once you have a high-quality, relatively complete mapping of sidewalks, I
> really think they add a lot of value. You can see where sidewalks end,
> where crossings are absent, how long crossings are, whether there is
> separation from other traffic by e.g. fence or bollards.
>
> It's not just about routing. Sidewalks (and crossings) are infrastructure
> in their own right and deserve to be mapped as such, at least in many dense
> urban areas, and especially where they vary significantly from street to
> street. I'm not saying it should be done everywhere, but it definitely does
> have value in some places.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-04-03 2:49 p.m., Frederik Ramm wrote:
>
> Hi,
>
> On 4/3/20 19:45, Martin Chalifoux via Talk-ca wrote:
>
> This morning I checked some large cities namely New-York, Paris, Amsterdam, 
> London, Berlin. Since OSM is best developed in Europe these capitals make 
> sense. I just checked Tokyo, Shangai, Seoul, Sydney to sample Asia. None of 
> them have this sidewalk mapping as separate ways.
>
> There are pockets here and there in Europe as well. Mostly what happens
> is this:
>
> 1. Someone wants to make a cool pedestrian/wheelchair/schoolkid routing
> project
>
> 2. The person or team has limited programming capability or budget, and
> hence must attack the problem with a standard routing engine
>
> 3. Standard routing engines do not have the capability to infer a
> sidewalk network from appropriately tagged streets (i.e. even if the
> street has a tag that indicates there's sidewalks left and right, the
> routing engine will not generate individual edges and hence cannot do
> something like "follow left side of X road here, then cross there, then
> follow right side" or so
>
> 4. Hence, tons of sidewalks (and often also pseudo-ways across plazas)
> are entered into OSM, to "make the routing work".
>
> (5. often people will then find that the routing engine generates
> instructions like "follow unnamed footway for 1 mile" which leads them
> to copy the road's name onto the sidewalk geometry... to "make the
> routing work").
>
> (6. In some countries a pedestrian is allowed to cross a street
> 

Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

2020-04-03 Thread John Whelan
Since it is dependent on municipal bylaws then I think it should be 
explicitly tagged.


Cheerio John

Pierre-Léo Bourbonnais wrote on 2020-04-03 2:05 PM:
The reason why we were asked to add them is for pedestrian security 
assessment and urban planning. When all sidewalks and crossing are 
mapped, we can measure crossing distances and estimate the probability 
of accidents, which can save lives when the cities add curb extensions 
(avancées de trottoirs). We use openstreetmap data to convince 
government officials that it is statistically better to take them into 
account when planning new neighbourhoods or enhance existing ones. 
Also, it allows us to get better precision and calculate penalties 
when routiong at traffic signals which must be crossed twice by 
pedestrian at some intersections. OpenStreetMap objective is to map 
what is there with the best precision available. When aerial 
photography was not precise enough for sidewalks, it was not feasible 
to add them, but now we get precise aerial photos that permit better 
representativity of the physical world. I can tell you that the amount 
of precision and completeness in openstreetmap data will increase 
rapidly in the coming years. And the COVID-19 pandemy will increase 
the need for precise and complete mapping of urban environments, so we 
must deal with it accordingly.
Mapping sidewalks as separate ways is now in the official wiki and has 
been accepted by the community by vote, so we must now find the best 
way to accomodate everyone. For now, I am just trying to know if we 
must add bicycle=no to them.


About the routing directions, we must add the street names to 
sidewalks (as we do in my team), otherwise like Martin said, routing 
engines will tell people to turn left, turn right instead of turn left 
on A street, then turn right on B street, etc.






On Apr 3, 2020, at 13:51, Harald Kliems > wrote:




On Fri, Apr 3, 2020 at 10:17 AM Martin Chalifoux via Talk-ca 
mailto:talk-ca@openstreetmap.org>> wrote:


What cities allow cycling on sidewalks anyway, seriously ? This
sounds so inadequate. That it is tolerated is one thing, but
outright legal or encouraged ? Makes no sense to me.

In the US that's pretty common. For example here in Madison 
(Wisconsin), sidewalk riding is generally allowed by ordinance, 
except where buildings directly abut the sidewalk (I manually tag 
those as bicycle=no).

 Harald.
___
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


--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

2020-04-03 Thread John Whelan
I'd recommend bicycle=no and I live in Ottawa.  In Ottawa footpaths that 
connect in general are bicycle=yes as they come under municipal 
regulation but a sidewalk on a highway comes under provincial 
legislation which bans bicycles on sidewalks.  Sparks street is fun I 
think you are not permitted to ride your bicycle but I'm unsure if this 
is provincial, municipal or it might even be NCC which is federal of course.


In the UK they are banned by law but in certain cities the Chief 
Constable has stated the law will not be enforced within the police 
force boundaries as a letter of interpretation.  It might be nice for 
Ottawa to do the same sometime but there again we have City of Ottawa 
police, OPP, RCMP and of course the PPS.


Cheerio John

James wrote on 2020-04-03 10:25 AM:
I don't think it's more tagging for the renderer as much as it's being 
more specific(more data) to specify a abstract view: without knowledge 
of Canadian/Provincial/Municipal laws about biking on sidewalks.


I think Montreal and Gatineau are more enforced as Ottawa it is 
illegal to bike on the sidewalk, but people are still doing it, but 
that's beside the point.


On Fri., Apr. 3, 2020, 10:18 a.m. Pierre-Léo Bourbonnais via Talk-ca, 
mailto:talk-ca@openstreetmap.org>> wrote:


Hi!

I would like to start a discussion on how we should deal with
sidewalks tagged separately, like it is is done in downtown Ottawa
and like we are starting to do in the Montreal region.

The issue is that by default highway=footway with or without
footway=sidewalk should have an implicit bicycle=no by default
according to this page:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions

However, some osm users told me I should tag them with bicycle=no
everywhere because routing engines use sidewalks for bicycle
routing which is illegal in most part of Canada.

What are your thoughts on this ? Should we adapt to routing
engines or should routing engines fix the issue themselves?

Thanks!


___
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


--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Canada Post offices

2020-03-28 Thread john whelan
It might be worthwhile highlighting those that do not have a postcode or
are tagged name=Canada Post.

Useful locally as I hadn't checked the ones I know of had been mapped nor
that their details were correct.  I did note one address was wrong, the
post office had moved from one side of the street to the other a year or so
ago.

Thanks John

On Sat, 28 Mar 2020 at 16:04, David E. Nelson via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> I have started a project with the objective of adding as many post offices
> as can be found in Canada to OpenStreetMap.
>
> Canada Post's own database yields just over 6000 post offices within the
> country, and I have used the Overpass API to determine that just over 2000
> of those, or only about one in every three such outlets, have already been
> added to OSM's database.
>
> I would like to enlist the help of mappers across Canada to add as many
> more of the missing post offices as they can find.  To that end, I have
> produced these spreadsheets detailing which post offices have already been
> added to OSM and which have not.
>
> Atlantic (A, B, C, E): <
> https://docs.google.com/spreadsheets/d/13O2oY4te6EvOPSqpaCOtWbUZ2UkO-ahq9CeODruvcDA/
> >
>
> Quebec (G, H, J):
> <
> https://docs.google.com/spreadsheets/d/1IOrbwQsEgSM8PvzWzBDHNPvM0d3HsiW_XLXYnK7utm8/
> >
>
> Ontario (K, L, M, N, P):
> <
> https://docs.google.com/spreadsheets/d/1k_mOmiL15L6ObCeJJ8DntVBXb21JSZwOsJTbfb1FOI0/
> >
>
> Western and Northern (R, S, T, V, X, Y):
> <
> https://docs.google.com/spreadsheets/d/1lcOL5ISS9aML6oaUOcgyngw4bio_gRmbxzLn-4GCjXQ/
> >
>
> Each spreadsheet has a "master list" of post offices, and each of those
> entries has been colour-coded according to their disposition:
>
> Green = Already added to OSM; node/way ID given, with dash before ID
> indicating a way, no dash indicating a node
> Red = Not yet added to OSM
> Yellow = Location listed on waymarking.com (although I am not sure
> waymarking.com data is licence-compatible with OSM) <
> https://www.waymarking.com/cat/details.aspx?f=1=610386da-84d0-4983-bdf1-7eb34a03e64b
> >
> Blue = Added to OSM, but since moved to a new location or simply needs to
> have its address re-verified
> Lilac = Postal code needs to be corrected—the correct postal code is in
> the spreadsheet; postal codes for Canada Post facilities *always* end with
> a zero
> Violet = A letter has been sent to that post office asking for its precise
> geographical location
>
> Each spreadsheet also has a second sheet titled "extraneous data",
> detailing which post offices found in the OSM data have been determined to
> have closed; which OSM post office data is redundant and needs to be
> merged, i.e., if a single post office location has both a way and a
> disconnected node describing it, in which case the tags from the node
> should be moved to the way; and which locations have been erroneously
> tagged as post offices.  Only locations branded as Canada Post where
> postage stamps can be purchased should have the "amenity=post_office" tag,
> while outlets branded as "FedEx", "UPS", or any other private courier
> should instead be tagged as "office=logistics".
>
> I would also like to see a harmonized tagging schema for Canada Post
> outlets, consisting as follows:
>
> addr:housenumber (Use ground survey or local knowledge wherever and
> whenever possible)
> addr:postcode (Use from spreadsheets)
> addr:street (Use ground survey or local knowledge wherever and whenever
> possible)
> amenity=post_office
> brand=Canada Post
> brand:wikipedia=en:Canada Post
> brand:wikidata=Q1032001
> name (Use from spreadsheets)
> operator (Either "Canada Post", for an outlet run directly by Canada Post,
> or for an independently-run franchise, the name of the business that the
> postal outlet can be found in)
> phone (Optional)
>
> I would prefer that no two or more post office locations share a postal
> code.  If this is not the case, only the outlet listed in the above
> spreadsheets should get tagged with "addr:postcode", while the others not
> use the "addr:postcode" tag at all.  As well, no two post office locations
> within the same province or territory should be permitted to have identical
> name values, and I have made sure of that in the spreadsheets.
>
> - David E. Nelson
> https://www.openstreetmap.org/user/DENelson83
> ___
> 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: [OSM-talk] fixme=name

2020-03-12 Thread John Whelan
But then you're often talking about a HOT mapper who might not have done 
any mapping for three years.


I must confess when validating HOT projects if I saw a mapper had done 
something glaringly wrong and it was more than a week before noting the 
response rate to a changeset message was less than 1% I may have simply 
corrected the work.


I haven't been on the ground in Africa but I suspect the number of 
villages a kilometre apart connected by a one kilometre motorway is not 
high.  If have I reclassified someone's private motorway  I apologise.


I think we have talked around the subject enough and it should be left 
to the local mappers to decide what to do.


Thanks John

Mateusz Konieczny via talk wrote on 2020-03-12 7:17 PM:




Mar 12, 2020, 23:54 by dieterdre...@gmail.com:



sent from a phone

On 12. Mar 2020, at 17:42, Marc M. 
wrote:

we may delete all fixme=name for all object without a name tag



I agree that fixme=name for missing names is pointless and could
be removed (although Andy has a point about not knowing someone’s
workflow, so for safety you could spare those added in the past
1-3 months). If there are other questions concerning the name it
would obviously have been better if they had been more explicit
about these potential problems in the fixme tag, but still, if
someone has added a fixme=name on an object with a name we should
keep it.

Though unspecific fixme=name is not very useful, I would ask in 
changeset that added this

what exactly is wrong/suspicious if I would encounter it during editing.

And yes, fixme=name on object without name is likely completely useless.
But I would also consider asking people adding it whatever it is used 
in any way.



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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] fixme=name

2020-03-12 Thread john whelan
I'm looking in Mali, looking at the history of a sample I'd say they were
HOT mapped and many are more than four years old.

Cheerio John



On Thu, 12 Mar 2020 at 09:29, Andy Townsend  wrote:

> On 12/03/2020 13:09, john whelan wrote:
>
> I'm seeing a fair number of settlements with this fixme tagged on them and
> I'm not sure what the logic is.
>
> There are 39k "fixme=name" worldwide.  I suspect usage varies greatly
> worldwide; it would be useful to know which ones you're looking at.
>
> The nearest few to me (at https://overpass-turbo.eu/s/Rxh , for info)
> seem to be either "name from one source disagrees with name from another
> source, needs more investigation" or "name was copied from an
> out-of-copyright map and is probably rubbish".
>
>
>
> I would have thought it is fairly simple to search for place=village
> without a name tag or am I missing something?
>
> It depends.  I'm guessing based on your previous list discussions, but
> perhaps someone's been remotely mapping areas that HOT or similar projects
> have an interest in, have identified a settlement from imagery but
> (obviously) do not know its name?
>
> Adding "fixme=name" doesn't add any value when the "name" tag is missing.
> as everyone can see that the name tag is missing.  Also, adding 1000s of
> new fixmes to an area (that add no value) will overwhelm the existing ones
> that aren't obvious (and I'm speaking as someone who regularly looks at
> local fixmes when out and about).  That said, I wouldn't mass-delete such
> fixmes either as you don't know what workflows people are using locally to
> try and correct these.
>
> With regard to searching, if someone is searching for a village by name
> then clearly they won't find it if it is unnamed, regardless of the search
> method.
>
> Best Regards,
>
> Andy
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] fixme=name

2020-03-12 Thread john whelan
I'm seeing a fair number of settlements with this fixme tagged on them and
I'm not sure what the logic is.

I would have thought it is fairly simple to search for place=village
without a name tag or am I missing something?

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


[OSM-talk] Please be gentle with newbies

2020-03-03 Thread john whelan
These days I'm retired and use my old age pensioner bus pass to grab a free
coffee.  Often there are strings attached like a group of politicans or
journalists etc. floating around.

Today I got cornered by one who had been on the receiving end of a
communication from a mapper saying they had made a mistake on their first
attempt at mapping.

It was a couple of years ago and the message was a little on the aggressive
side.  The receiver still remembers it clearly and in their mind OSM was a
well this not the place to use those sort of words.

When you send a message to a mapper you don't know who they are.  You are
representing OpenStreetMap when you send a message so please put your
passion to one side and be gentle with the poor things if only so I can
enjoy my free coffee in peace.

I do sympathize, I've come across a lot of suboptimal mapping in my time
and mentally expressed exactly the same thoughts that were expressed but I
do try to count to ten before sending a polite note that says did you
really mean to map this this way?  Have you read the wiki here which gives
guidance?

And yes I know those who read this mailing list would always be polite but
I couldn't think where else to post it.

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


Re: [Talk-ca] James work on Task Manager

2020-02-24 Thread John Whelan
From memory you're based in Cobourg and Port Hope in Ontario.   
Squamish is in BC so may not be local to you.


The Ottawa cycle club did some mapping in OSM 
https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide you may find 
this useful.


Task manager is better suited to imports and to mapping from satellite 
data.


If you're on the ground then Street Complete, or Vespucci on android are 
useful, also OSMand for adding POIs.  iD on a windows laptop or tablet.  
There are editors for Apple Ios avaulbale but I'm not familiar with them.


JOSM is about the most powerful editor but it doesn't run on a 
smartphone as far as I am aware.


If you just want to add to Mapillary then their web site will show you 
what has been photographed so far and it isn't very much in Cobourg or 
Port Hope.


I'm not sure what the advantage of having a task set up on task manager 
would be.


Have fun

Cheerio John

jonab...@gmail.com wrote on 2020-02-24 8:24 AM:


When James has finished tweaking the Task Manager, I would like to 
test it out with our local bike club along with Mapillary streetview. 
http://tasks.openstreetmap.in/project/84


Jonathan



Hi all,

I was able to split Squamish into Quadtree tiles with a maximum of 200 
buildings each. James is now looking into whether/how this could be 
implemented in the task manager. If no one else is volunteering to be 
the local import manager this week, I will do the work and contact 
Squamish's local mappers. Since most ODB buildings were imported about 
a year ago, I don't expect an opposition from local mappers with 
reviewing that import.




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] James work on Task Manager

2020-02-24 Thread john whelan
Are you simply asking for a task to be set up or something else?

James currently is looking at the data to import then resizing the squares
to better fit the task.

I don't think there are any plans to import buildings in your local area.
I seem to recall mapping a thousand or so  manually in JOSM so the locals
you organised could add detail.  I seem to recall we got one address added
by the locals.

Cheerio John

On Mon, Feb 24, 2020, 8:26 AM ,  wrote:

> When James has finished tweaking the Task Manager, I would like to test it
> out with our local bike club along with Mapillary streetview.
> http://tasks.openstreetmap.in/project/84
>
>
>
> Jonathan
>
>
>
> 
>
> Hi all,
>
> I was able to split Squamish into Quadtree tiles with a maximum of 200
> buildings each. James is now looking into whether/how this could be
> implemented in the task manager. If no one else is volunteering to be the
> local import manager this week, I will do the work and contact Squamish's
> local mappers. Since most ODB buildings were imported about a year ago, I
> don't expect an opposition from local mappers with reviewing that import.
>
>
>
>
> ___
> 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: [OSM-talk] Testing torrents for the planet dump

2020-02-09 Thread John Whelan

My concern would be more the volume of data we have whirling round.

Smaller torrents of each country might be more useful and I'd have to 
get my head around picking up the new one each week.  I'm running 
qBittorrent if that is of any use.


Cheerio John

Christian Quest wrote on 2020-02-09 12:42 PM:


Le 09/02/2020 à 18:26, Maarten Deen a écrit :

On 2020-02-09 16:17, Christian Quest wrote:

A couple of weeks ago, I've (re) started sharing planet dump files
using Bittorrent to test an alternative way to distribute our planet
dumps to reduce the bandwidth load on the OSMF servers.

Here is a short summary after 2 weeks tests...

The torrents are generated a few hours after the planet dump
availability on planet.openstreetmap.org server (time needed to
download the original file to generate the torrent).


A question about updates of the torrent. The planet changes weekly. 
Suppose I download the plannet using the torrent and then also seed 
it, what happens when the next planet comes available? Do I need to 
use a different torrent to download it again or will the one I have 
be updated?
Each planet file has its own torrent. A new planet file means using a 
new torrent to download it.


To simplify downloading the lastest planet, you'll find a 
planet-latest.pbf.torrent similar to the planet-latest.pbf (it's a 
symlink to the last planet available).


If you want to automate downloading new planet thru torrents, for 
example to seed them, there's a rss.xml file you can use. Many 
bittorrent clients support RSS to automate downloads.




--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-ca] Importing buildings in Canada

2020-01-25 Thread john whelan
We should start somewhere so yes it would be fun.

Thanks John

On Sat, Jan 25, 2020, 3:15 PM Daniel @jfd553,  wrote:

> Bonjour groupe,
>
> The pre-processing procedure has been tested for the Squamish (BC) area.
> Squamish has a small number of buildings (6K) with a good Esri World
> imagery which need to be aligned with ODB data. A large number of ODB
> buildings show an inaccurate delineation (shaky drawing with too many
> nodes). Orthogonalization worked great but the result is not perfect
> because of the quality of the data. About 10% of the nodes were removed
> from the dataset. It contains all the problems we may encounter during this
> import. Consequently, I suggest that the import procedure be discussed and
> documented in detail using this case.
>
> I could identify myself as the local import manager, but I would much
> prefer someone from the area to volunteer. When the local contributors have
> been contacted, and as long as there are no objections, we could start an
> import project in the OSMCanada task manager. Pre-processed data are
> available. We only have to make it available to the task manager. We also
> have to provide the task manager with the working areas (tasks) adjusted to
> 200 buildings per task. I am currently working to define these working
> areas, but if someone else can build it in the meantime it would be great.
>
> Once the import project has been configured in the task manager,
> interested contributors will have to identify themselves in talk-ca in
> order to add them as authorized contributors (James, am I right?)
>
> Would it be fun to try this?
>
> Daniel
>
>
> ___
> 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: [OSM-talk] Teaching cyclists how to contribute to OSM

2020-01-19 Thread john whelan
Locally in Ottawa many paths are multiuse there is a path many kilometers
long along the Ottawa river that has a line marked down the center and is
very much used by cyclists but according to NCC who own the path it is
multi-use not bicycles only so is mapped highway=path.  Most City of Ottawa
paths are the same, bicycles are permitted but they are not cycleways.

I worked with City of Ottawa bicycle specialist on this starting on why one
path in a park was marked as a bicycle path whilst another in the same park
of identical width was not.  Eventually we arrived at all paths except
those that are marked no bicycles are multiuse paths ie bicycles are
permitted.

Multiuse means skateboards, wheelchairs, skis  etc.  We had 25 cms of snow
today and many paths are not ploughed.  There aren't many conventional
bicycles that can use the paths under these conditions.

Cheerio John

On Sun, 19 Jan 2020 at 18:42, Paul Johnson  wrote:

>
>
> On Sat, Jan 18, 2020 at 5:06 PM James  wrote:
>
>> Bike advocacy group in Ottawa created this:
>>
>>
>> https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md
>>
>> as well as a crowd sourced map like the one for winter bike trails that
>> allows a user to submit if a path is winter maintained or not, it will then
>> update OSM in the back end: maps.bikeottawa.ca
>>
>
> Did notice an error.  It's suggesting a cycleway with a sidewalk be tagged
> as highway=path instead of highway=cycleway.
> ___
> 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] Importing buildings in Canada

2020-01-18 Thread john whelan
Sounds very reasonable to me.

Thanks John

On Sat, 18 Jan 2020 at 20:02, Nate Wessel  wrote:

> In short, yes. But we should give them a clear option and a clear path
> toward doing it either way - written procedures, provide preprocessing
> scripts/help, etc.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-01-18 7:37 p.m., john whelan wrote:
>
> > But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> My interpretation is you're happy to leave this call to the local
> coordinator?  If they have no buildings it's fairly simple if there are
> buildings already mapped it becomes more complex.
>
> Thanks John
>
> On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:
>
>> Hi all,
>>
>> Daniel, thanks for continuing to prod the conversation along :-)
>>
>> I guess the point of disagreement here is that I generally don't agree
>> that the ODB buildings are of higher quality than what's already in OSM.
>> The ODB data I've seen is quite messy, and IMO only marginally better than
>> having no data in an area, especially if not properly checked and conflated
>> with surrounding OSM data. People seem to generally disagree with that
>> perspective though, so I'll assume that other areas are better represented
>> by their respective ODB data sources. Central Toronto may just not have
>> been well mapped by the City's GIS dept; it certainly isn't the easiest
>> thing to get right.
>>
>> My real worry here is that someone will be carelessly going through an
>> import replacing geometries and will destroy the work of an editor like
>> myself who carefully contributed their time to make a neat and accurate
>> map. I know for certain I've contributed better data in Toronto than what's
>> available from government sources for the same area.
>>
>> We must recall that governments produce building footprints in the same
>> way that we do - usually by tracing imagery, and there is little reason to
>> suppose that their data is better or more accurate just because it comes
>> from a seemingly authoritative source. It comes from interns - likely
>> interns with outdated software and low-resolution surveys.
>>
>> All that being said, I think my real reluctance to go with the flow here
>> stems from the haste and carelessness of the original importers in the GTA.
>> We're working toward a process that should be very different from theirs
>> though and I probably need to just trust that our process will be calmer,
>> slower, and more thoughtful. If it is, I can get on board.
>>
>> But also - sorry this is such a long email - we certainly should not be
>> manually doing re-conflation where buildings are very dense (e.g. downtown
>> Toronto) or where they have already been imported extensively (much of the
>> rest of the GTA). The import plan I'm working on for Toronto will take care
>> of most of this automatically by importing only in the sparse gaps between
>> existing OSM buildings. For other parts of Canada, this may not be much of
>> an issue at all - I wouldn't know.
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>>
>> Bonjour groupe,
>>
>> Here is a sequential summary of the last exchanges. I inserted some
>> comments […] within these exchanges description and summarize what I
>> understand from it at the end.
>>
>> *Nate* asked not to confuse the process of importing new data with that
>> of updating/modifying existing OSM data in order to keep things simple for
>> this import.
>>
>> *Daniel* (I) responded that importing new data and updating/modifying
>> existing ones at the same time (when necessary) is not unusual in OSM [*and
>> would be more efficient*].
>>
>> *John* replied that importing new data and updating/modify existing data
>> when required worked quite nicely when importing Ottawa.
>>
>> *Nate *explained he believes that the buildings will not be compared
>> manually since there are hundreds of 

Re: [Talk-ca] Importing buildings in Canada

2020-01-18 Thread john whelan via Talk-ca
> But also - sorry this is such a long email - we certainly should not be
manually doing re-conflation where buildings are very dense (e.g. downtown
Toronto) or where they have already been imported extensively (much of the
rest of the GTA). The import plan I'm working on for Toronto will take care
of most of this automatically by importing only in the sparse gaps between
existing OSM buildings. For other parts of Canada, this may not be much of
an issue at all - I wouldn't know.

My interpretation is you're happy to leave this call to the local
coordinator?  If they have no buildings it's fairly simple if there are
buildings already mapped it becomes more complex.

Thanks John

On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:

> Hi all,
>
> Daniel, thanks for continuing to prod the conversation along :-)
>
> I guess the point of disagreement here is that I generally don't agree
> that the ODB buildings are of higher quality than what's already in OSM.
> The ODB data I've seen is quite messy, and IMO only marginally better than
> having no data in an area, especially if not properly checked and conflated
> with surrounding OSM data. People seem to generally disagree with that
> perspective though, so I'll assume that other areas are better represented
> by their respective ODB data sources. Central Toronto may just not have
> been well mapped by the City's GIS dept; it certainly isn't the easiest
> thing to get right.
>
> My real worry here is that someone will be carelessly going through an
> import replacing geometries and will destroy the work of an editor like
> myself who carefully contributed their time to make a neat and accurate
> map. I know for certain I've contributed better data in Toronto than what's
> available from government sources for the same area.
>
> We must recall that governments produce building footprints in the same
> way that we do - usually by tracing imagery, and there is little reason to
> suppose that their data is better or more accurate just because it comes
> from a seemingly authoritative source. It comes from interns - likely
> interns with outdated software and low-resolution surveys.
>
> All that being said, I think my real reluctance to go with the flow here
> stems from the haste and carelessness of the original importers in the GTA.
> We're working toward a process that should be very different from theirs
> though and I probably need to just trust that our process will be calmer,
> slower, and more thoughtful. If it is, I can get on board.
>
> But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe,
>
> Here is a sequential summary of the last exchanges. I inserted some
> comments […] within these exchanges description and summarize what I
> understand from it at the end.
>
> *Nate* asked not to confuse the process of importing new data with that
> of updating/modifying existing OSM data in order to keep things simple for
> this import.
>
> *Daniel* (I) responded that importing new data and updating/modifying
> existing ones at the same time (when necessary) is not unusual in OSM [*and
> would be more efficient*].
>
> *John* replied that importing new data and updating/modify existing data
> when required worked quite nicely when importing Ottawa.
>
> *Nate *explained he believes that the buildings will not be compared
> manually since there are hundreds of thousands of them in OSM for Toronto
> alone. In other words, he thinks there will be automated edits, and these
> edits are not governed by the same policies as imports. [*This is an
> important consideration. What has happened in Ottawa and Toronto so far?
> Have automatic processes been used?*]
>
> *Tim* replied that in most cases it might be appropriate to replace OSM
> data, as he believes [*as I do for most of the cases*] that the ODB
> footprints will be more accurate than existing buildings. However he
> considers it is a case-by-case decision [*then no automation process
> should be used*].
>
> *John* couldn’t resist digressing toward the “Microsoft buildings import”
> but had to bring back the discussion on ODB import after reactions from
> *Tim* and *Pierre* (LOL).
>
>
>
> I think that, somehow, we could all agree on how the import should be done:
>
> -  Align images on ODB, unless evidence ODB data are ill located.
>
> -  Align existing OSM content with the image, *only* 

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Thread john whelan
Pierre looking at the Microsoft imports south of the border and their
process is undoubtedly sensible.

I suggest waiting until we have got some movement on the current import
rather than try to tackle to many things at once.

Cheerio John

On Fri, Jan 17, 2020, 1:47 PM Pierre Béland,  wrote:

> John,
>
> Exprime tu simplement une opinion, ou as-tu vérifié les procédures
> d'import incluant correction des données et validé la qualité des données
> importées aux États-Unis ? Considères-tu la qualité des données dans la
> base OSM aux États-Unis comparable à ce qui s'est fait au Canada l'an
> dernier ?
>
> La qualité des données Microsoft peut sans doute varier selon divers
> facteurs dont la qualité et précision des données aériennes utilisées.
>
> De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le
> gestionnaire de tâches US, il est possible d'y repérer les tâches créées
> pour cartographier des bâtiments.
>
> https://tasks.openstreetmap.us/contribute?difficulty=ALL=ARCHIVED=BUILDINGS
>
> Dans ces zones, j'ai constaté en général une bonne qualité des données.
> Je ne connais pas les procédures utilisées, ni regardé le connu des
> fichiers de données Microsoft pour ces zones, mais la tâche ci-dessous
> montre un processus de validation où il était demandé d'orthogonaliser les
> bâtiments.
> https://tasks.openstreetmap.us/project/164#bottom
>
> Pierre
>
>
> Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> > As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM.
>
> Well yes that is one opinion but we do have a range of opinions in
> OpenStreetMap and from the number of buildings that have already been
> imported into OpenStreetMap from Microsoft, there seems to be a large
> number in the US for example, it would appear there are those who disagree
> with you which is not surprising given the number of mappers.
>
> To me the buildings are of more interest once they get enriched with more
> tags and the place that happens is in OpenStreetMap.  Streetcomplete I
> think is either the most popular editor these days or very close to it.
> You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
> display the outlines by using the Microsoft data but that does not show
> tags such as building type, building levels, etc etc. and streetcomplete is
> a tool that can be used to introduce OpenStreetMap to many people.
>
> I think perhaps we should concentrate our efforts on the current import
> for the moment but I suspect that some Microsoft buildings will start to be
> imported in Canada even if they don't have an official import plan.
>
> Cheerio John
>
>
> On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:
>
> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  <mailto:o...@elrick.de>> wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Thread john whelan
> As stated before, I don't consider the Microsoft dataset being close to
the minimum quality requirements I would expect from any automated
building entry into OSM.

Well yes that is one opinion but we do have a range of opinions in
OpenStreetMap and from the number of buildings that have already been
imported into OpenStreetMap from Microsoft, there seems to be a large
number in the US for example, it would appear there are those who disagree
with you which is not surprising given the number of mappers.

To me the buildings are of more interest once they get enriched with more
tags and the place that happens is in OpenStreetMap.  Streetcomplete I
think is either the most popular editor these days or very close to it.
You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
display the outlines by using the Microsoft data but that does not show
tags such as building type, building levels, etc etc. and streetcomplete is
a tool that can be used to introduce OpenStreetMap to many people.

I think perhaps we should concentrate our efforts on the current import for
the moment but I suspect that some Microsoft buildings will start to be
imported in Canada even if they don't have an official import plan.

Cheerio John


On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:

> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  <mailto:o...@elrick.de>> wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>  replace already existing objects. However, I think this is a case by
>  case decision. However, I think it is important to keep tags and
>  history
>  of buildings already existent in OSM. This is how I would
>  read/interpret
>  the import guideline stated by Nate: "If you are importing data where
>  there is already some data in OSM, then *you need to combine this
> data*
>  in an appropriate way or suppress the import of features with overlap
>  with existing data." (emphasis added by me)
>
>  However, that just means, the import, hence, is nothing easy and could
>  not be achieve quickly, I would assume. One way of making sure that
>  this
>  is dealt with diligently, would be setting the tasking manager to
>  'experienced mappers only'. We would have to ask James, who is in
>  charge
>  of the Canada Tasking Manager, how to edit/set up the 'experienced
>  mapper role' in the TM. It might be possible to feed in a list of
>  mappers manually or to set a threshold of objects/changesets that they
>  must have entered in OSM. However, maybe only mappers who feel
>  experienced enough to handle the import would contribute to the TM
>  project anyway and we let everyone judge on their own and don't
>  restrict
>  access.
>
>  If we were to separate the new and overlapping buildings, I am also
>  leaning towards Daniel's assessment. I would be afraid to cause more
>  issues than by doing it all at once (with a reasonable tile size, of
>  course).
>
>  In the end, the main point of importing this specifi

Re: [Talk-ca] Importing buildings in Canada

2020-01-17 Thread john whelan
>first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without Stat
Can data we are happy to import Microsoft dataset buildings as is?  Or
would we wish to wait until we have some more imports done before looking
at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  wrote:

> I would assume in most cases the imported building footprint will be
> more precise than existing data. For me, this would be a reason to
> replace already existing objects. However, I think this is a case by
> case decision. However, I think it is important to keep tags and history
> of buildings already existent in OSM. This is how I would read/interpret
> the import guideline stated by Nate: "If you are importing data where
> there is already some data in OSM, then *you need to combine this data*
> in an appropriate way or suppress the import of features with overlap
> with existing data." (emphasis added by me)
>
> However, that just means, the import, hence, is nothing easy and could
> not be achieve quickly, I would assume. One way of making sure that this
> is dealt with diligently, would be setting the tasking manager to
> 'experienced mappers only'. We would have to ask James, who is in charge
> of the Canada Tasking Manager, how to edit/set up the 'experienced
> mapper role' in the TM. It might be possible to feed in a list of
> mappers manually or to set a threshold of objects/changesets that they
> must have entered in OSM. However, maybe only mappers who feel
> experienced enough to handle the import would contribute to the TM
> project anyway and we let everyone judge on their own and don't restrict
> access.
>
> If we were to separate the new and overlapping buildings, I am also
> leaning towards Daniel's assessment. I would be afraid to cause more
> issues than by doing it all at once (with a reasonable tile size, of
> course).
>
> In the end, the main point of importing this specific dataset fulfils
> two purposes, in my opinion: first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset), second, to get the best geospatial representation possible in
> our OSM database. That means, we defer from using the Microsoft dataset
> and use the much higher quality data from the ODB. This also means that
> we should replace already existing buildings (yet keeping tags and
> history) wherever the ODB footprint is more precise than the existing one.
>
> Just my two cents here,
> Tim
>
> ___
> 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] Building tags in Canada

2020-01-16 Thread john whelan
That sort of works but doesn't include roof:levels.

The easy tag would be building=detached but then you get building=house
which can be used for a semi detached house.

Locally we have some split levels so a single floor at ground level then a
garage often slightly sunk with another room or two on top.
building:levels=?

I'm tempted by the idea of using Streetcomplete's set of suggested tags.

Postcode is fine if you know it but it isn't always obvious from looking at
the building on the outside.

I think what is in the wiki is a sort of dream.  An accurate building date
for example is often difficult to determine. but probably it needs a sort
of low hanging fruit section of what should be easy to tag.

Thanks John

On Thu, 16 Jan 2020 at 17:49, stevea  wrote:

> On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> > Is there somewhere that offers guidelines on how to add additional tags?
> and which tags are more interesting and which should be avoided?   For
> example country=Canada is probably superfluous.
>
> As it hasn't been touched in five months, I'm not sure how applicable the
> wiki
>
>
> https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped
>
> is, relevant to how "this" is being done today.  This effort's wikis and
> approaches have changed — and grown!— since that document was drafted.
>
> But, that section does indicate that OSM's "key building=* currently has
> over 60 documented values" and the "man_made=* key now has over 50
> documented values."  I do recall when I selected eight or ten of the values
> noted there that I was largely making educated guesses.  But now, as is
> true of wiki, especially during a project that is still sort of "wet cement
> being mixed" (nothing wrong with that, it has to happen, it happens well
> now) please feel free to modify these values as you see fit.  It was meant
> to be a starting point, may you continue with it as well as possible.  (Or
> not).
>
> SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] Building tags in Canada

2020-01-16 Thread John Whelan
Part of the building import was the idea that once an outline was in 
place it could be tagged with more detail by someone with local 
knowledge. Sometimes some of this this information might be available 
from Mapillary.


For example building=house rather than building=yes

In Coburg there are a number of buildings labelled roof:levels=1

My understanding is this means a room in the attic which is fine but if 
you'd noted the attic room would it not make sense to map the number of 
levels as well?


Is there somewhere that offers guidelines on how to add additional tags? 
and which tags are more interesting and which should be avoided?   For 
example country=Canada is probably superfluous.


Thanks John

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] FW: Re: Importing buildings in Canada

2020-01-16 Thread john whelan
My understanding is that is when we imported Ottawa we followed the normal
process as detailed by Daniel and that seemed to work quite nicely.

Cheerio John

On Thu, Jan 16, 2020, 2:57 PM Daniel @jfd553,  wrote:

> Hello Nate,
>
> I understand that you don’t like to see an import process that both bring
> in new objects and overwrite existing ones. You also suggest removing
> "overlapped" building from ODB prior to import it. Such pre-processing,
> that would ensure there will be no buildings "overwrite" during the import,
> is not realistic (i.e. you will need to overwrite some buildings anyway).
> Here are two reasons why it would be difficult...
>
> 1-  OSM is a dynamic project and, unless you can "clean" the data on
> the fly, you will end up with overlaps since some contributors will have
> added buildings in the meantime.
>
> 2-  One cannot assume that an OSM building, and its ODB counterpart,
> will be found at the same location (look at DX and DY columns in ODB
> inventory tables). These are averages, which means there are larger offsets
> between both datasets (i.e. you won’t get a match between buildings, or get
> a match with the wrong ones).
>
> The only realistic option is then to manually delete the ODB buildings if
> they overlap OSM ones. Here is what the import guideline suggests [1]…
>
> "If you are importing data where there is already some data in OSM, then
> you need to combine this data in an appropriate way or suppress the import
> of features with overlap with existing data."
>
> Therefore, importing data and using a conflation process is not unusual.
> Again, I understand that in case of an overlap, you go for the last option
> (suppress the import building). I am rather inclined toward using
> conflation when necessary, which means...
>
> -  Importing an ODB building when there is no corresponding one
> in OSM;
>
> -  Conflating both ODB and OSM buildings when it significantly
> improves existing OSM content;
>
> -  Not importing an ODB building when the corresponding one in
> OSM is adequate.
>
> What do the others on the list think?
>
> Daniel
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data
>
>
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Thursday, January 16, 2020 10:38
> *To:* Daniel @jfd553; talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> Responding to point C below,
> I would strongly suggest that we not confuse the process of importing new
> data with that of updating/modifying existing data in the OSM database. One
> of the things I really disliked about the initial building import was that
> it overwrote existing data at the same time that new data was brought in.
> These are really two separate import processes and require very different
> considerations.
>
> We can certainly consider using this dataset to improve/update existing
> building geometries, but I think that is a separate process from the import
> we are discussing here. To keep things simple for this import, I would
> suggest removing any building from the import dataset that intersects with
> an existing building in the OSM database. That is, let's not worry about
> conflation for now, and come back and do that work later if we still feel
> there is a strong need for it.
>
> I see the main point of this effort as getting more complete coverage - it
> we want to use the dataset to do quality assurance on existing data, that
> is a whole other discussion.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
>
> Thanks for the quick replies!
>
> Now, about...
>
> *a) Data hosting:*
>
> Thank you James, I really appreciate your offer (and that of others). So
> yes, I think hosting pre-processed data in the task manager, for approved
> regions, is an attractive offer. When we agree on a municipality for
> pre-processing, I will contact you to make the data available.
>
> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
> manager. I understand that ODB data are currently converted on the fly when
> requested?
>
> *b) Task manager work units for import:*
>
> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
> was thinking at the same importation rate, but for an hour of work. It
> seems best to target 20-minute tasks.
>
> *c) Task manager work units for checking already imported data*
>
> According to Nate, it is definitely not faster than actively importing. We
> should then keep the above setup (b).
>
> However, what if I add a new tag to pre-processed data indicating if a
> building was altered or not by the orthogonalization (and simplification)
> process? For instance, *building:altered=no*, would identify buildings
> that were not changed by the process and that could be left unchanged in
> OSM (i.e. 

Re: [Talk-ca] Importing buildings in Canada

2020-01-15 Thread John Whelan

I'll cross my fingers and hope it all comes together.

Thanks John

Tim Elrick wrote on 2020-01-15 5:18 PM:

Hi all,

I understand your concerns, John. However, many mappers might not 
follow talk-ca. So, I guess, Daniel's suggestion to contact them, 
might work better than waiting for them to incidentally check talk-ca.


* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of 
changesets, ie. presumably experienced mappers. The disadvantage is 
that these changesets do not have to be from the area we are 
interested in (however, with activity center in the last 6 months we 
at least make sure they were working in our area); another 
disadvantage is that you cannot collect the names of the mappers 
easily (or am I missing something here?). The advantage of the 
overpass query is that you get that list of names easily and you can 
see how many objects they have added in your area in the past months. 
The disadvantage, of course, is that we don't know how experienced the 
mappers are (but maybe this doesn't matter).


Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:

for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be 
send out to local mappers that include the everything that Daniel 
suggested in his last message below.


Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.


IMHO, we just need to make sure that we have done everything 
reasonable to inform the concerned contributors, in order to discuss 
the import in case they do not agree with it. That is why I proposed 
the following, in a previous email, concerning local mappers buy-in…


1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.

3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there 
is no or only a few answers. The identification of local contributors 
using Neis’ tool, or the query Tim Elrick just proposed, are what I 
consider reasonable attempts for contacting the local mappers.


Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour 
tasks


*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
    // I collected users active in the last 6 months, but you can
    // change that
    node(newer:"{{date:6 months}}")(area.searchArea);
    way(newer:"{{date:6 months}}")(area.searchArea);
    relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. First, zoom to the area of interest (i.e. your
bounding box), then paste the following code on the left and export:

// overpass query
[out:csv(::user)];
(
    node(newer:"{{date:6 months}}")({{bbox}});
    way(newer:"{{date:6 months}}")({{bbox}});
    relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I 

Re: [Talk-ca] FW: Re: Importing buildings in Canada

2020-01-15 Thread john whelan
One concern I have at present is the lack of comments from what I would
call more average mappers in smaller population areas.

The conversation seems to be limited to two or three players.

I'm not sure if this is because we lost momentum earlier or people now feel
they have to have made more than a hundred edits to get involved.

We know the major cities have something worked out or are working on it.

My concern is more those locations with a smaller population and fewer
mappers who may not follow this list.

Cheerio John

On Wed, Jan 15, 2020, 1:05 PM James,  wrote:

> Just to let you know there is a maximum of geometry the tasking manager
> can handle, I'm not exactly sure what it is, but I have encountered it
> before. So try not to go too ham with the geometric shapes
>
> On Wed., Jan. 15, 2020, 12:56 p.m. Daniel @jfd553, 
> wrote:
>
>> Thanks for the quick replies!
>>
>> Now, about...
>>
>> *a) Data hosting:*
>>
>> Thank you James, I really appreciate your offer (and that of others). So
>> yes, I think hosting pre-processed data in the task manager, for approved
>> regions, is an attractive offer. When we agree on a municipality for
>> pre-processing, I will contact you to make the data available.
>>
>> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
>> manager. I understand that ODB data are currently converted on the fly when
>> requested?
>>
>> *b) Task manager work units for import:*
>>
>> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
>> was thinking at the same importation rate, but for an hour of work. It
>> seems best to target 20-minute tasks.
>>
>> *c) Task manager work units for checking already imported data*
>>
>> According to Nate, it is definitely not faster than actively importing.
>> We should then keep the above setup (b).
>>
>> However, what if I add a new tag to pre-processed data indicating if a
>> building was altered or not by the orthogonalization (and simplification)
>> process? For instance, *building:altered=no*, would identify buildings
>> that were not changed by the process and that could be left unchanged in
>> OSM (i.e. not imported); *building:altered=yes* for those who were
>> changed by the process and that should be imported again. The same
>> pre-processed datasets could then be made available for all cases. Thoughts?
>>
>> *d) Finding local mappers:*
>>
>> I agree with Nate’s suggestion to try contacting the top 10 mappers in an
>> area. Using the "main activity center" would work for most of the
>> contributors but selecting other overlays (.e.g. an activity center over
>> last 6 months) could also work great. As long as we identify who might be
>> interested in knowing there is an import coming.
>>
>> Comments are welcome, particularly about the proposal on c)
>>
>> Daniel
>>
>>
>> ___
>> 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] FW: Re: Importing buildings in Canada

2020-01-15 Thread john whelan
I think we should have a list of ways to find local mappers.

Ideally we start with Pascal Neis’ tool  but then allow ourselves to reduce
the bar to consider others perhaps with 9 changesets or less after two
weeks after approaching the ideal mapper /mappers first.

Do we have a target municipality at the moment of reasonable data  that
doesn't need cleaning up so we can start there?

If need be I can host on jaws.org but I'm more than happy for James to do
so.

Cheerio John

On Wed, 15 Jan 2020 at 08:35, Daniel @jfd553  wrote:

> Bonjour Groupe,
>
> Concerning the proposal (ODB import), there are questions that remain
> before moving forward; here are some of them…
>
> a)  Who on this list host the ODB data? If pre-processing is
> required, how should we proceed to have the results made available
> (assuming I ran the pre-process)?
>
> b)  Nate mentioned that the working units (shapes) proposed by the
> task manager are customizable according to data density. So, how many
> buildings can be imported properly (i.e. following the procedure) in an
> hour or so? Would it be a good size to proceed?
>
> c)   There are areas where the data has already been imported. What
> would be the size of an import check task? I expect that a much larger
> number of buildings can be checked in an hour or so, but by how much (10x)?
>
> d)  Who should be contacted when trying to get the local mappers
> buy-in? IMHO I would contact only those found by Pascal Neis’ tool [1],
> which would have contributed more than 10 changesets and for which the main
> activity centre is within a the concerned municipality (tick/untick the
> display option boxes [1]).
>
> Proposals or comments you which to share?
>
> Daniel
>
> [1] Overview of OpenStreetMap Contributors aka Who’s around me?
> http://resultmaps.neis-one.org/oooc?
>
> *From:* Daniel @jfd553 [mailto:jfd...@hotmail.com]
> *Sent:* Saturday, January 11, 2020 15:41
> *To:* talk-ca@openstreetmap.org
> *Subject:* [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> By the way, have a look at
>
> https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
> https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings
>
> Cheers
>
>
> ___
> 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] Importing buildings in Canada

2020-01-05 Thread john whelan
Which is what I imagined was the case but the audience in talk-ca is large
and with two languages around it is easy for misunderstandings to occur.

Cheerio John

On Sun, Jan 5, 2020, 12:33 PM Nate Wessel,  wrote:

> John,
> Those links were just to indicate what can be done with task setup. I
> don't think we're close to setting up actual import tasks yet, though we do
> seem to be on the road toward getting things sorted out :-)
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-01-05 12:20 p.m., john whelan wrote:
>
> I'm getting lost as to who is organising what and who is taking
> responsibility for defining and setting up the tasks and where they are
> being set up.
>
> Are your two examples of what can be done?  Or are they to be used by
> mappers to add buildings?
>
> My understanding was Daniel would identify those areas that looked the
> most interesting then these would be set up after the process to see if any
> local mappers were available and what their input would be.
>
> Thanks John
>
> On Sun, Jan 5, 2020, 11:41 AM Nate Wessel,  wrote:
>
>> The task size, and even shape is totally customizable. I've set up a
>> couple that are entirely based on the density of the data:
>> http://tasks.osmcanada.ca/project/168
>> https://tasks.openstreetmap.us/project/107
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>> On 2020-01-04 12:40 p.m., Daniel @jfd553 wrote:
>>
>> Bonjour groupe
>>
>>
>>
>> Looks like we're going in the same direction so far :-)
>>
>> I agree with Nate regarding the implementation of the task manager. In my
>> experience, a size of a few blocks would be better in urban areas, but
>> boring in rural areas. Is it something that can be adjusted?
>>
>>
>>
>> Daniel
>>
>>
>>
>> *From:* Nate Wessel [mailto:bike...@gmail.com ]
>> *Sent:* Saturday, January 04, 2020 10:09
>> *To:* talk-ca@openstreetmap.org
>> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>>
>>
>>
>> Hi Daniel,
>>
>> Thank you for all the work you've put into this. I'd like to offer a
>> couple suggestions and/or clarifications for your proposed import process,
>> overview though it is.
>>
>> First, I think it is very important that a tasking manager is set up on a
>> city/by city basis only, and that only AFTER consensus is achieved that the
>> import should proceed in that area. I would really like to avoid seeing the
>> massive nationwide tasking that was set up the first time around. We should
>> be making it hard for people to go rogue in regions where consensus for an
>> import doesn't (yet) exist.
>>
>> Related to this, though important enough to be a second point in it's own
>> right, the tasking squares need to be small enough that a single user can
>> manage them and inspect every single building in a task. The first round of
>> import used task squares that were massive, and which couldn't be divided
>> any further past a certain point. Even in rural areas, it is likely
>> inappropriate to import areas larger than 1km^2. In central Toronto it
>> would be (and was) idiotic. An import that doesn't take local scale into
>> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
>> big to import in my opinion and is not a good enough benchmark for import
>> batch sizing.
>>
>> That is, each import needs to be local, and not just in a superficial
>> sense.
>>
>> I'll also add that the issue of conflation doesn't seem to have been
>> worked out yet except to note that it is an issue. What will we do with the
>> millions of buildings which will substantially overlap/duplicate existing
>> buildings or imports? This needs to be worked out in detail before anything
>> starts up again.
>>
>> And what needs to be done about already existing low quality imports?
>> It's good to acknowledge their existence, but what will be done about them?
>> We've set up a task to clean up some of the mess in Toronto (
>> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
>> iceberg.
>>
>> Again, I thank everyone for their time and effort on this - we can get
>> this done if we go slow and do it right :-)
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>>
>> On 2020-01-03 3:40 p.m., 

Re: [Talk-ca] Importing buildings in Canada

2020-01-05 Thread john whelan
I'm getting lost as to who is organising what and who is taking
responsibility for defining and setting up the tasks and where they are
being set up.

Are your two examples of what can be done?  Or are they to be used by
mappers to add buildings?

My understanding was Daniel would identify those areas that looked the most
interesting then these would be set up after the process to see if any
local mappers were available and what their input would be.

Thanks John

On Sun, Jan 5, 2020, 11:41 AM Nate Wessel,  wrote:

> The task size, and even shape is totally customizable. I've set up a
> couple that are entirely based on the density of the data:
> http://tasks.osmcanada.ca/project/168
> https://tasks.openstreetmap.us/project/107
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-04 12:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe
>
>
>
> Looks like we're going in the same direction so far :-)
>
> I agree with Nate regarding the implementation of the task manager. In my
> experience, a size of a few blocks would be better in urban areas, but
> boring in rural areas. Is it something that can be adjusted?
>
>
>
> Daniel
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com ]
> *Sent:* Saturday, January 04, 2020 10:09
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the 

Re: [Talk-ca] Importing buildings in Canada

2020-01-04 Thread john whelan
Daniel addressed this if you reread his email and proposal.  Basically we
look for local mappers first.  If we don't find any we increase the
distance for local.

At the moment we are discussing the stats can sourced data.

My feeling is let's get this import moving once more and to do that let's
aim at those areas with good data, a local mapper or two and we can tackle
the more complex ones later.

Those areas with no local mappers are also areas where we probably need to
use Microsoft or another source of data.  Each separate source will need a
separate overall import plan together with "subplans" which is what I'll
call Daniel's idea of tackling the stat can data an area at a time.

Cheerio John

On Sat, Jan 4, 2020, 4:07 PM Matthew Darwin,  wrote:

> Hello all,
>
> Happy to see progress here.
>
> My ongoing question is how to define that a "local" group has determined
> that an import can proceed.   And more specifically what is "local"? There
> are rural and remote parts of Canada which have in the order of zero active
> mappers or sense of a local community.  How do we consensus around imports
> there? Can we get agreement by (part-of) province/territory where there is
> not some other group that puts their hand up?  (maybe use admin level 5
> boundaries, with holes for big cities)
>
> I just want to make sure we don't stop at doing imports only for big
> cities. Buildings are important for the whole country.
> On 2020-01-04 10:09 a.m., Nate Wessel wrote:
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. 

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Thread john whelan
Sounds sane to me.

Thanks John

On Fri, 3 Jan 2020 at 16:05, Daniel @jfd553  wrote:

> Hi John,
>
> To comply with the import directive, I would like the discussion to
> continue on the current ODB import only. Could we talk about other sources
> of potential imports at another time? -)
>
>
>
> Thanks
>
> Daniel
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Friday, January 03, 2020 15:57
> *To:* Daniel @jfd553
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Sounds sane to me.
>
>
>
> Are we thinking of setting up a second import to handle Microsoft building
> outlines on a similar basis? Or extending this one?  I only ask since if we
> are doing it municipality by municipality it might be an idea to identify
> those municipalities that do not have suitable open data through stats
> canada.  I can see us with a list of municipalities and a data source and I
> think it probably should be in one place.
>
>
>
> Cheerio John
>
>
>
> On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go

Re: [Talk-ca] Importing buildings in Canada

2020-01-03 Thread john whelan
Sounds sane to me.

Are we thinking of setting up a second import to handle Microsoft building
outlines on a similar basis? Or extending this one?  I only ask since if we
are doing it municipality by municipality it might be an idea to identify
those municipalities that do not have suitable open data through stats
canada.  I can see us with a list of municipalities and a data source and I
think it probably should be in one place.

Cheerio John

On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:

> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go ahead with the
> import once everything settled. For those who already made the import, I
> suggest that they review their work since many issues were detected with
> some of these imports.
>
> Since there are only a few local OSM communities in Canada, and because
> Canada is large, I suggest not limiting the import of a given municipality
> to the people of the concerned province or region.
>
> *2.2 Pre-processing*
>
> Once local mappers have agreed, some pre-processing can be done if
> required.
>
> A few months ago, I developed a tool that could be used to process the
> data [4]. Concerns were raised because the application was developed using
> proprietary software. So I documented the whole process and algorithms in
> order to see courageous coders converting it in open source software. In
> the meantime, and as long as I have access to an FME licence, I could
> process the data, when 

Re: [OSM-talk] is OSM a fake map.

2019-12-29 Thread john whelan
I'm fairly lucky in that in the last three years nothing much has changed
locally.  The highways have stayed much the same.  Most buildings are still
there.

If you use Bing to add things then realistically it fills in gaps in the
map.  If you delete things because they are not in Bing that is a quite
different matter.

Does it matter if the mapper lives more than five miles away?  Well I've
mapped places a few thousand miles away but they were places I knew very
well as I used to live there.

I don't think OSM will ever be completely accurate.  Having said that it is
still very useful for many purposes.

Cheerio John


On Sun, 29 Dec 2019, 12:31 80hnhtv4agou--- via talk, 
wrote:

> it say in some wiki. to correct what you find wrong on the map,
>
> not one “other nearby users” is a current mapper, and all edits in a 5
> mile radius are not coming from an on the ground
>
> mappers in my area but 20 miles + away and are tracing from bing, and the
> images on bing in my local area are from
>
> 2016 so i do not see how the map locally is true, and it is not easy to go
> and see every thing they have done,
>
> no car or bike.
>
> every thing i do is backed up by me on mapillary, and in traces.
> ___
> 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] Importing buildings in Canada

2019-12-24 Thread john whelan
There are some areas of reasonable quality where buildings are missing.
These I think can be imported on the technical side without too much
difficulty and those were the ones I cherry picked as low hanging fruit
that should not be contentious.

Having said that I have seen the view expressed it is better to have poor
quality data created by local mappers in OSM than high quality data by
expert mappers so it may well be contentious .

In Ottawa buildings were not imported to overwrite existing buildings.
Basically the missing ones were imported by experienced mappers.  That is
just process and I think we have the process fairly well documented and
defined.

There are three sources of building data with the right license in Canada.
Bing is one and that almost certainly covers Newfoundland so Newfoundland
is involved to some extent.

For data that is deemed in need of cleanup or squaring again we can come up
with a process to do that and we have experienced mappers who can follow
the agreed process.

I suggest we hold back for a few days before getting into a heavy
discussion.

Cheerio John



On Tue, 24 Dec 2019 at 18:30, Adam Martin  wrote:

> Hi all,
>
> Looking at the wiki page, a large volume of the buildings are of low
> quality requiring processing.  The trade off here is between not having
> buildings and having buildings that are out of place and of poor quality.
> I can see people being reluctant to have it imported in an area, especially
> where buildings have been drawn by hand.  If this is to be imported, I
> think many would be more amenable to the idea if the data already present
> was given precedence.
>
> As a Newfoundlander, the lack of any such data for this province could be
> a blessing or a curse, depending on how you see the mass importation of
> buildings.
>
> Happy holidays!
>
> Adam
>
> On Tue., Dec. 24, 2019, 7:36 p.m. Daniel @jfd553, 
> wrote:
>
>> Have a look at the wiki page I referred to. Further discussions will be
>> more easy and focused
>>
>> Sent from Galaxy S7
>>
>> --
>> *From:* John Whelan 
>> *Sent:* Tuesday, December 24, 2019 2:50:29 PM
>> *To:* James 
>> *Cc:* Daniel @jfd553 ; Talk-CA OpenStreetMap <
>> talk-ca@openstreetmap.org>
>> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>>
>> I think the first problem to be addressed is the presence or absence of a
>> local community.
>>
>> In the north we have few mappers but lots of interested agencies and
>> people in seeing the buildings imported.
>>
>> Montreal I think is under control.  Toronto is in the process of sorting
>> itself out but I'm unclear how much territory the Toronto local group
>> covers.
>>
>> Vancouver should be big enough to support a local group.  As should
>> Calgary and Edmonton.
>>
>> Ottawa is complete as is Gatineau.
>>
>> It's the smaller cities and regions that would be my concern.  Often it
>> will be by chance that two or more mappers meet occasionally.
>>
>> So step one can we list the local groups?
>>
>> I also have a problem with what happens if two people agree but haven't
>> done any mapping are they a local group?
>>
>> Step two to me would be a consensus on how to tackle those areas without
>> a local group and I think Daniel's suggestion would be a way forward in
>> this area.
>>
>> Cheerio John
>>
>>
>>
>> James wrote on 2019-12-24 1:28 PM:
>>
>> wasn't there talk about this before and someone blocked it because of
>> non-square buildings and the resulting discussion was that each community
>> was going to decide if they want to import or not?
>>
>> On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, 
>> wrote:
>>
>> Hi Group!
>>
>> I am currently working on a proposal which, I hope, will bring consensus
>> among the community and relaunch the import of ODB footprints (StatCan).
>> The proposal should be ready in a few weeks, or sooner.
>>
>>
>>
>> In the meantime, I suggest to all those who are interested to take note
>> of the observations I made regarding these data. This information can be
>> found in the OSM wiki (1). According to OSM import guideline requirements,
>> it describes the data to import. At the same time, I updated the
>> Canada-federal section of the Data Potential wiki page (2).
>>
>>
>>
>> I will be offline in the next few days, so if you have any
>> questions/comments, please be patient :-)
>>
>>
>>
>> Daniel
>>
>>
>>
>> 1 - https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

Re: [Talk-ca] Importing buildings in Canada

2019-12-24 Thread John Whelan
So an approach would be to pick off those areas with good data available 
first with few existing buildings mapped?


Such as Victoria or Courtenay in BC

Burlington, Caledon, Barrie in Ontario

Then move forward based on that experience?

I'd feel more comfortable with a mapper from the province at least 
coordinating the mapping even if there wasn't a local group.


How would we tackle places such as Perth? Smith Falls and Brockville 
which are available in Bing if not other sources?  These are in Ontario 
and fairly local to Ottawa by the way.


Thanks John

Daniel @jfd553 wrote on 2019-12-24 6:04 PM:
Have a look at the wiki page I referred to. Further discussions will 
be more easy and focused


Sent from Galaxy S7


*From:* John Whelan 
*Sent:* Tuesday, December 24, 2019 2:50:29 PM
*To:* James 
*Cc:* Daniel @jfd553 ; Talk-CA OpenStreetMap 


*Subject:* Re: [Talk-ca] Importing buildings in Canada
I think the first problem to be addressed is the presence or absence 
of a local community.


In the north we have few mappers but lots of interested agencies and 
people in seeing the buildings imported.


Montreal I think is under control.  Toronto is in the process of 
sorting itself out but I'm unclear how much territory the Toronto 
local group covers.


Vancouver should be big enough to support a local group.  As should 
Calgary and Edmonton.


Ottawa is complete as is Gatineau.

It's the smaller cities and regions that would be my concern.  Often 
it will be by chance that two or more mappers meet occasionally.


So step one can we list the local groups?

I also have a problem with what happens if two people agree but 
haven't done any mapping are they a local group?


Step two to me would be a consensus on how to tackle those areas 
without a local group and I think Daniel's suggestion would be a way 
forward in this area.


Cheerio John



James wrote on 2019-12-24 1:28 PM:
wasn't there talk about this before and someone blocked it because of 
non-square buildings and the resulting discussion was that each 
community was going to decide if they want to import or not?


On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, <mailto:jfd...@hotmail.com>> wrote:


Hi Group!

I am currently working on a proposal which, I hope, will bring
consensus among the community and relaunch the import of ODB
footprints (StatCan). The proposal should be ready in a few
weeks, or sooner.

In the meantime, I suggest to all those who are interested to
take note of the observations I made regarding these data. This
information can be found in the OSM wiki (1). According to OSM
import guideline requirements, it describes the data to import.
At the same time, I updated the Canada-federal section of the
Data Potential wiki page (2).

I will be offline in the next few days, so if you have any
questions/comments, please be patient :-)

Daniel

1 -
https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

2 -

https://wiki.openstreetmap.org/wiki/Potential_Datasources#Federal_.28Open_Government.29

___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca



___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca


--
Sent from Postbox <https://www.postbox-inc.com>


--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Importing buildings in Canada

2019-12-24 Thread John Whelan
I think the first problem to be addressed is the presence or absence of 
a local community.


In the north we have few mappers but lots of interested agencies and 
people in seeing the buildings imported.


Montreal I think is under control.  Toronto is in the process of sorting 
itself out but I'm unclear how much territory the Toronto local group 
covers.


Vancouver should be big enough to support a local group.  As should 
Calgary and Edmonton.


Ottawa is complete as is Gatineau.

It's the smaller cities and regions that would be my concern.  Often it 
will be by chance that two or more mappers meet occasionally.


So step one can we list the local groups?

I also have a problem with what happens if two people agree but haven't 
done any mapping are they a local group?


Step two to me would be a consensus on how to tackle those areas without 
a local group and I think Daniel's suggestion would be a way forward in 
this area.


Cheerio John



James wrote on 2019-12-24 1:28 PM:
wasn't there talk about this before and someone blocked it because of 
non-square buildings and the resulting discussion was that each 
community was going to decide if they want to import or not?


On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, > wrote:


Hi Group!

I am currently working on a proposal which, I hope, will bring
consensus among the community and relaunch the import of ODB
footprints (StatCan). The proposal should be ready in a few weeks,
or sooner.

In the meantime, I suggest to all those who are interested to take
note of the observations I made regarding these data. This
information can be found in the OSM wiki (1). According to OSM
import guideline requirements, it describes the data to import. At
the same time, I updated the Canada-federal section of the Data
Potential wiki page (2).

I will be offline in the next few days, so if you have any
questions/comments, please be patient :-)

Daniel

1 - https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

2 -

https://wiki.openstreetmap.org/wiki/Potential_Datasources#Federal_.28Open_Government.29

___
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


--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


  1   2   3   4   5   6   7   8   9   10   >