Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

There are several conflicting perspectives here.
My objective is to give addresses to people who will never have one. Last
year I was living in a city in Africa ( 6GVW2FXH+4H
<https://www.openstreetmap.org/#map=17/7.04700/38.47910>) with a population
of a half a million people.  None of the streets and roads have names, nor
are there any house numbers in that city or any of the surrounding rural
areas where most of the population lives.  As the population in Africa
migrates to urban settings in the next few decades the cities will be
expanding greater than governments' ability to create infrastructure,
including addresses, to support the populations.
Plus codes is a practical solution to provide addresses that are usable by
both humans and machines. It is interesting that this effort for addressing
is being trashed because it is savvy technology.  Plus code can be
calculated on the fly, but if they are to be used we will need to have
hardcopy maps with the addresses that can be used to direct aid workers to
a specific location. Just because something could be done doesn't mean that
it will or should be done.  If we provide easy access to an address as an
attribute for OSM it will get used. I don't understand what problems would
be created by adding valuable information to an address point.  So far I
see no practical solution for giving an address to the billions of people
that do not have one, just because a tag value has intelligence and
practical value is no reason to throw it away.

On Fri, Aug 10, 2018 at 6:05 AM, john whelan  wrote:

> A simple stopgap solution would be a program that converted one to the
> other where the result could be cut and pasted into another program.  They
> are probably called apps these days.
>
> If you know the code it would give you the lat and long in a format that
> could be searched by Nominatim.
>
> Grabbing the lat and long from the map and converting it needs a process.
>
> Suggestions?
>
> Thanks John
>
> On Fri, 10 Aug 2018, 8:58 am john whelan,  wrote:
>
>> I would agree the import should be reverted.  The data is redundant and
>> there is a danger that it might not be correct.  The pure lat and long data
>> already in OSM can be used to calculate the code.
>>
>> It does add weight to the idea of making them searchable perhaps with a
>> JOSM plugin and support in OSMand for off line use and Nominatim for on
>> line use.
>>
>> Cheerio John
>>
>> On Fri, 10 Aug 2018, 8:50 am Michael Reichert, 
>> wrote:
>>
>>> Hi,
>>>
>>> Am 2018-08-09 um 22:48 schrieb Vao Matua:
>>> > The Tanzania Development trust has calculated the Plus Code addresses
>>> for
>>> > 17 million building points in Tanzania and have added a sample village
>>> > (1800 points) as a test.
>>> > https://www.openstreetmap.org/changeset/59213224
>>> >
>>> > The Python code on Github works great to calculate Plus Codes.
>>> >
>>> > We did used these tags:
>>> > addr:pluscode:full  (the 8+2 digit full Plus Code)
>>> > addr:pluscode:area (the first 4 digits of the full Plus Code which is
>>> a 1
>>> > degree by 1 degree lat long area)
>>> > addr:pluscode:local (the second 4 digits + last 2 digits which used
>>> with a
>>> > local name becomes the local address)
>>>
>>> There is no need for this data in OSM because the data can be retrieved
>>> automatically from latitude and longitude (plain coordinates) which are
>>> already assigned to anything which has a location on the planet.
>>>
>>> Adding Plus Code tags to OSM objects is as useful as adding latitude=*
>>> and longitude=* or any other coordinate system which can be calculated
>>> from latitude and longitude.
>>>
>>> This import should be reverted.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>> ___
>>> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

I use Plus Codes with OSMand offline and it works well. If we are worried
about the number of tags we should remove all tags and convince everyone to
just use lat/long.
The ability to verbally tell someone a location like 47RP+XG Dar-es-Salaam
is much easier than -6.85748/39.28613
Suspend disbelief, sometimes new things are better.

On Thu, Aug 9, 2018 at 2:57 PM, john whelan  wrote:

> So if OSMand or some such could handle them in a search off line that
> would be acceptable?  They are generated from long and lat after all.
>
> My feeling is adding them to Nominatim is not a perfect solution as it
> implies OpenStreetMap supports them rather than something else but from a
> practical point of view it would solve a lot of problems.  Not least the
> idea that tags get added to every building with some sort of address code.
> How many different codes for buildings are we going to see?
>
> Currently locally addr: has number, postcode and street name so its
> difficult to logically say its one rule for one country and another for a
> different one.
>
> Cheerio John
>
> On 9 August 2018 at 17:40, Vao Matua  wrote:
>
>> It is a good idea for the unconnected part of the world. If you have
>> access to a website you might as well use three-silly-words.
>> If you have a stand-alone app with the Plus Codes on the buildings then
>> someone can easily communicate that information.
>> Internet connectivity is not world wide.
>>
>> On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm 
>> wrote:
>>
>>> Hi,
>>>
>>> On 08/09/2018 10:48 PM, Vao Matua wrote:
>>> > The Tanzania Development trust has calculated the Plus Code addresses
>>> > for 17 million building points in Tanzania and have added a sample
>>> > village (1800 points) as a test.
>>>
>>> This is not a good idea. Please don't do it. It does not make sense! If
>>> someone searches for a plus code on a web site, the site can compute the
>>> lat/lon and take you there, WITHOUT having to add billions of plus code
>>> points all over the word.
>>>
>>> Bye
>>> 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
>>
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

It is a good idea for the unconnected part of the world. If you have access
to a website you might as well use three-silly-words.
If you have a stand-alone app with the Plus Codes on the buildings then
someone can easily communicate that information.
Internet connectivity is not world wide.

On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm  wrote:

> Hi,
>
> On 08/09/2018 10:48 PM, Vao Matua wrote:
> > The Tanzania Development trust has calculated the Plus Code addresses
> > for 17 million building points in Tanzania and have added a sample
> > village (1800 points) as a test.
>
> This is not a good idea. Please don't do it. It does not make sense! If
> someone searches for a plus code on a web site, the site can compute the
> lat/lon and take you there, WITHOUT having to add billions of plus code
> points all over the word.
>
> Bye
> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

The Tanzania Development trust has calculated the Plus Code addresses for
17 million building points in Tanzania and have added a sample village
(1800 points) as a test.
https://www.openstreetmap.org/changeset/59213224

The Python code on Github works great to calculate Plus Codes.

We did used these tags:
addr:pluscode:full  (the 8+2 digit full Plus Code)
addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
degree by 1 degree lat long area)
addr:pluscode:local (the second 4 digits + last 2 digits which used with a
local name becomes the local address)

On Thu, Aug 9, 2018 at 6:48 AM, Stefano  wrote:

> Hi,
> there's already a pull request
> https://github.com/openstreetmap/openstreetmap-website/pull/1818
>
> Stefano
>
> Il giorno gio 9 ago 2018 alle ore 15:45 Yuri Astrakhan <
> yuriastrak...@gmail.com> ha scritto:
>
>> I'm a big fan of plus codes, and even have a pending implementation of it
>> in the Elasticsearch (as an aggregation hashing function).  I doubt there
>> are any legal restrictions on using this - the code is licensed under
>> Apache 2, and Google states "Plus codes are free. There are no licensing
>> fees or other costs. The technology is open-sourced." at
>> https://plus.codes/
>> Not sure about the implementation complexities.
>>
>> On Thu, Aug 9, 2018 at 4:35 PM oleksiy.muzal...@bluewin.ch <
>> oleksiy.muzal...@bluewin.ch> wrote:
>>
>>> Open Location Codes are also referred to as "plus codes".  Since August
>>> 2015, Google Maps supports plus codes in their search engine. The algorithm
>>> is Open Source, licensed under the Apache License 2.0. and available on
>>> GitHub [1].
>>>
>>> A plus code, can be generated at: https://plus.codes/ . It can be
>>> entered at the Google Maps search input box to find a location. A plus sign
>>> "+" is inserted in the code for recognition.
>>>
>>> It would be nice to have an interoperability. For example, a customer
>>> uses Google Map, but a dispatcher in a Call Center the OpenStreetMap. The
>>> OLC has got some interesting features:
>>>
>>> "Open Location Codes are derived from latitude and longitude
>>> coordinates, so they already exist everywhere. They are similar in length
>>> to a telephone number -- 849VCWC8+R9, for example -- but can often be
>>> shortened to only four or six digits when combined with a locality
>>> (CWC8+R9, Mountain View). Locations close to each other have similar codes.
>>> They can be encoded or decoded offline. The character set avoids similar
>>> looking characters, to reduce confusion and errors, and avoids vowels to
>>> make it unlikely that a code spells existing words.The Open Location Code
>>> is not case-sensitive, and can therefore be easily exchanged over the
>>> phone." [1]
>>>
>>> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>>>
>>> Best regards,
>>> Oleksiy
>>>
>>> ___
>>> 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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [HOT] Why the HOT obsession with low quality buildings in Africa ?

[Vao Matua]

When you say "low quality" buildings, do you mean the quality of the
polygon data or are you judging someone's home to be of low value?

On Mon, Jul 2, 2018 at 1:24 AM, Jean-Marc Liotier  wrote:

> Active in Senegal and Mali, I have noticed that changesets tagged with
> tasking-manager HOT projects produce very large numbers of buildings.
> Those buildings appear to be of very low quality. I wonder: who uses
> this data ?
>
> If it is only necessary to assess that people live there, then a
> landuse=residential is sufficient
>
> If it is necessary to count the number of dwelling units to infer
> population, then a node is sufficient (maybe along with an attribute to
> discriminate single or multi-tenancy)
>
> If the geometry is actually necessary, then I wonder if anyone is
> satisfied with those semi-random shapes that, with some optimism, may be
> identified as being in the vicinity of actual buildings (most of the
> time)
>
> Enthusiastic contributors expend an awful lot of effort in flooding the
> map with low-quality buildings. I have seen ruins, building parts,
> walls, vague shadows on the ground, rubbish heaps, market stalls, cars
> and trucks all tagged as buildings - and I'll charitably keep from
> commenting on the geometric quality of those that attempt to map actual
> buildings (and I'll leave aside the issue of HOT leads requiring the use
> of outdated imagery such as Bing instead of ESRI World in Bamako). Is it
> the most useful way to channel the energy of inexperienced contributors
> ?
>
> I often find myself wishing that HOT leads introduce them to
> Openstreetmap through Osmose quality control rather than by churning out
> buildings like demented stonemasons trying to reach their weekly quota
> of gamified task-managing !
>
> ___
> HOT mailing list
> h...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to map alleys in African cities?

[Vao Matua]

I agree with Pierre's description of highway=residential and highway=path.
I also believe it is a good idea to tag driveways and roads to compounds as
*highway=service*.

A problem I commonly see in residential areas in Africa is highway=track.
It seems to be a little condescending for remote mappers to tag roads as
tracks just because they don't look like residential roads in Europe or
North America.

Another recurring problem is highway=living_street, this tag is misleading
and confusing for native English and non-native English speakers alike.

If the road provides access to a couple of dwellings and doesn't connect
through to other roads then *highway=service* is appropriate. One exception
I suppose would be an "alley" behind houses that just goes between two
other residential roads.  In that case the classification is based on
function due to a construction constraint (the width).

Regards,

Emmor


On Tue, Nov 14, 2017 at 2:30 PM, Andrew Buck 
wrote:

> Pierre's suggestions are a good guideline in general and I don't have
> any disagreements with them.
>
> I did, however want to expand a bit on the idea of when to use service
> roads, so here is that...
>
> I for one am in favor of additionally making liberal (but careful) use
> of highway=service.
>
> A service road is like a residential road, but is not meant to be used
> for "through traffic" but rather as the first or last leg of a longer
> journey.  With this in mind, I offer up the following example as a good
> guideline (or case study) of how this should look in practice:
>
> Several years ago, I traced the roads in Ibadan, Nigeria.  It was nearly
> a blank map when I started so I had complete freedom in deciding how to
> classify them (this was years before "highway tag africa").  I started
> by just marking nearly everything as highway=residential.  Then after
> the whole city was mapped I spend some time just looking at the finished
> map and the roads overlaid on the satellite imagery.  After taking in
> this "whole city view" for a while I began to see patterns in how the
> roads were laid out, and these patterns suggested which roads should be
> downgraded to service.
>
> In the case of Ibadan there are little "pocket communities" of people,
> separated by streams with a few roads crossing the streams but a dense
> network within each community.  So after digesting the map, and seeing
> how the town was structured, I decided I would downgrade all the roads
> that only served to access buildings within one community, but were not
> part of the routing if you were traveling outside of the community.
> This lead to a marked improvement in the quality of the map, which you
> can see in the two links below.  Although I finished tracing all the
> roads, I didn't finish all the classifications, so you can see a good
> "before and after" of how much better it looks with proper use of
> service roads.
>
> Here is a "before" section where all the roads are left as residential:
>
>   https://www.openstreetmap.org/#map=15/7.3354/3.9118
>
> And here is an "after" section where I have downgraded local-access-only
> roads to service but left the rest as residential.  Notice how much more
> clearly you can see the neighborhoods, and also how much easier it is to
> follow a route, without having to use a route planning tool.  You can
> navigate just by looking at the map.
>
>   https://www.openstreetmap.org/#map=15/7.3933/3.9598
>
> In the second example above you can actually see some areas of all
> residential to the east, so there is a very clear difference between the
> two sections.
>
> Obviously every town will be slightly different, but I think this is the
> general rule we should follow:
>
>if you use the road mainly for accessing buildings (even if it is
>a fairly large number of them) but not for long distance travel,
>then the road should be downgraded to service.
>
> After you spend a bit of time looking at the whole town, and keeping
> this rule in mind, you will get a good sense of what to downgrade.  Then
> it is just a matter of going through and applying it.
>
> Anyway, hope this all makes sense to people.  I had been meaning to
> write it up for a while now and this seemed like a good opportunity.
> Maybe I will try to go through and finish up Ibadan, I am a lot faster
> at this now than I was back then, so it wouldn't take me long.  I will
> leave it for the time being so it doesn't break the examples.  If people
> think this sounds reasonable, maybe we should grab some before and after
> screenshots for the wiki to document this.
>
> -AndrewBuck
>
>
>
>
> On 11/14/2017 03:30 PM, john whelan wrote:
> > That seems very sensible.
> >
> > Thanks John
> >
> > On 14 November 2017 at 16:26, Pierre Béland  wrote:
> >
> >> I we follow the Highway Tag Africa wiki page I initiated in 2013, narrow
> >> highways should be evaluaed on the type of traffic possible
> >> - highway= residential