[OSM-talk] DWG looking for Chinese translation help

2016-08-16 Thread Paul Norman
The OSM Foundation Data Working Group is looking for help with 
translating a couple of messages to Chinese. These messages are about 
data we're going to need to redact, so we want to make sure they understand.


If you can help, please contact d...@osmfoundation.org


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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Jóhannes Birgir Jensson

Þann 16.08.2016 00:24, Nicolás Alvarez reit:

2016-08-15 21:13 GMT-03:00 Daniel Koć :
If we have no current backup available, I think it would be good to 
have a
script harvesting all the entries even just via plain HTML, with 
publishing
date, username and user id, so we could recreate it more or less on 
the new
server. Old backup may have some value, but most of the time fresh 
content

is what really matters.


ArchiveTeam.org is already doing this HTML backup.


With access to forums you only see after login?

As for "no panic" then we've got several projects cooking in Iceland 
after a beneficial annual meeting but we've not launched them yet 
because we don't want to fragment any more than strictly needed so the 
forum issue has been plaguing us. We could set up our own forum and go 
from there but that is counter-productive in the long run.


We would like the matter to be resolved shortly, pumping up enthusiasm 
and belief in projects is hard work and harder when the organizational 
tools we wanted to adhere to are broken (in this case in a logistical 
more than technical way).


--Jóhannes

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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Hakuch
On 16.08.2016 11:45, Jóhannes Birgir Jensson wrote:
> Þann 16.08.2016 00:24, Nicolás Alvarez reit:
>> ArchiveTeam.org is already doing this HTML backup.

> With access to forums you only see after login?

The scraping is not about a html-backup. What we would need for
transfering the old posts into a new forum software is the raw DB Data.
If we cant get them from the server itself, we have to reproduce it from
the html view. My script is able to do that.

> As for "no panic" then we've got several projects cooking in Iceland
> after a beneficial annual meeting but we've not launched them yet
> because we don't want to fragment any more than strictly needed so the
> forum issue has been plaguing us. We could set up our own forum and go
> from there but that is counter-productive in the long run.

as this new-server-software project will take some time. How do you
think about hijacking another country-subforum? There are a lot where no
one is active with only very few posts. I would accept it as temporary
solution.


0x3CBE432B.asc
Description: application/pgp-keys
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Daniel Koć

W dniu 16.08.2016 12:04, Hakuch napisał(a):


as this new-server-software project will take some time. How do you
think about hijacking another country-subforum? There are a lot where 
no

one is active with only very few posts. I would accept it as temporary
solution.


No need to invade Uruguay or Venezuela (both low volume with last 
activity in March)... ;-P I think general chat is the best place to 
start, since it is also low volume and may be used for things which have 
no better place to be discussed - especially with subjects like 
"[Iceland] National parks":


http://forum.openstreetmap.org/viewforum.php?id=9

If Lambertus ever wake up, it will be just a matter of pushing them to a 
new subforum, so nothing would be lost and no fragmentation will occur. 
If not, it will still be easy to do on a new server.


It would be a pity to not start community work just because there is no 
optimal place!


--
"Low, low, low..." [M. Kempa]

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


[OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Dave F

Hi

I've heard a claim from a user who still wants to use the is_in:* tag as 
well as boundary tags that Nominatim uses is_in as preference because 
"geospacial mathematics is resource intensive".


Is this true?

I thought geospacial calculations were fairly light on processing power.

I also thought is_in:* was to be discouraged. Being hard coding, if a 
boundary was to change all affected entities would become inaccurate.


Thanks
Dave F.

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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Microgamer
As Hakuch already says: The project "new server" will take some time.
I don't know what all has to be done, to fire up the server, set the admins 
into position etc.
I think that we should go with an other forum, because fluxbb seems not to be 
that easy to handle.
Then all software we need has to be installed on the server. Then the forum 
itself comes onto the server.
This is the time when we have to have a template which matches the OSM style. 
Several plugins have to been written/installed. E.g. the OAuth-Plugin.

In general for the server i would expect that we have 3 admins and a 3rd 
organisation (OSMF) with credentials for the server, the database and the 
forum-administration. So this case cannot happen. More rights for the mods are 
possible as well :DD

So it's a bit of work and i think we should start as fast as possible with this 
project.
With the freeze-time sb has already said, Iceland has to wait at least 4 weeks 
for their forum to be installed. So we don't have that much time.
I assume that some organisation, probably the OSMF, has to put the admins into 
power. So sb, whe knows the system better than me, should probably write the 
procedure here.

An other thing I don't understand... Why do we have to wait, when the current 
admin didn't answer the question from iceland for some month already?

RegardsMicro


Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.


 Original Message 
Subject: Re: [OSM-talk] Forum admin(s) wanted
Local Time: 16. August 2016 12:40 PM
UTC Time: 16. August 2016 10:40
From: dan...@xn--ko-wla.pl
To: talk@openstreetmap.org

W dniu 16.08.2016 12:04, Hakuch napisał(a):

> as this new-server-software project will take some time. How do you
> think about hijacking another country-subforum? There are a lot where
> no
> one is active with only very few posts. I would accept it as temporary
> solution.

No need to invade Uruguay or Venezuela (both low volume with last
activity in March)... ;-P I think general chat is the best place to
start, since it is also low volume and may be used for things which have
no better place to be discussed - especially with subjects like
"[Iceland] National parks":

http://forum.openstreetmap.org/viewforum.php?id=9

If Lambertus ever wake up, it will be just a matter of pushing them to a
new subforum, so nothing would be lost and no fragmentation will occur.
If not, it will still be easy to do on a new server.

It would be a pity to not start community work just because there is no
optimal place!

--
"Low, low, low..." [M. Kempa]

___
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] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Hakuch
following the wiki, its not deprecated

https://wiki.openstreetmap.org/wiki/Key:is_in

However, I really would love to see a scheme that shows how nominatim
finds it results..

On 16.08.2016 15:29, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:* tag as
> well as boundary tags that Nominatim uses is_in as preference because
> "geospacial mathematics is resource intensive".
> 
> Is this true?
> 
> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if a
> boundary was to change all affected entities would become inaccurate.
> 
> Thanks
> Dave F.
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



0x3CBE432B.asc
Description: application/pgp-keys


0x3CBE432B.asc
Description: application/pgp-keys
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Andy Townsend

On 16/08/2016 16:19, Hakuch wrote:

following the wiki, its not deprecated

https://wiki.openstreetmap.org/wiki/Key:is_in


I was surprised when I read that the other day too...


However, I really would love to see a scheme that shows how nominatim
finds it results..


There's the nominatim.openstreetmap.org site (but that might not be want 
you want).


http://nominatim.openstreetmap.org/details.php?place_id=660625

Doesn't explicitly mention "is_in", but I guess you could try it 
somewhere there are enclaves and exclaves and see what it returns.


Best Regards,

Andy


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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Sarah Hoffmann
On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:*
> tag as well as boundary tags that Nominatim uses is_in as preference
> because "geospacial mathematics is resource intensive".
> 
> Is this true?

Not at all. Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.

It is true that it still understands is_in:* tags but prbably not in
the way you would think. First of all, they are completely ignored
on anything at building level (e.g address points and POIs). For
everything else Nominatim always uses a geospatial match when
computing the address. is_in:* is just good to help make a decision
when there are two equally well suited candidates, generally when, say,
a road is right between two city place nodes. As soon as there are
boundaries, multiple candidates don't happen anymore, so that is_in:*
is ignored for all practical purposes.

> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if
> a boundary was to change all affected entities would become
> inaccurate.

Yes, if possible always draw boundaries. They are more precise and easier
to maintain. is_in is unnecessary.

Kind regards

Sarah

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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Hakuch
Hey Sarah, do you have documentations that explain how nominatim
processes the queries? That could be an answer to questions like that one

On 16.08.2016 21:27, Sarah Hoffmann wrote:
> On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
>> Hi
>>
>> I've heard a claim from a user who still wants to use the is_in:*
>> tag as well as boundary tags that Nominatim uses is_in as preference
>> because "geospacial mathematics is resource intensive".
>>
>> Is this true?
> 
> Not at all. Nominatim happily processes boundaries and always prefers
> it over any other hierarchy information.
> 
> It is true that it still understands is_in:* tags but prbably not in
> the way you would think. First of all, they are completely ignored
> on anything at building level (e.g address points and POIs). For
> everything else Nominatim always uses a geospatial match when
> computing the address. is_in:* is just good to help make a decision
> when there are two equally well suited candidates, generally when, say,
> a road is right between two city place nodes. As soon as there are
> boundaries, multiple candidates don't happen anymore, so that is_in:*
> is ignored for all practical purposes.
> 
>> I thought geospacial calculations were fairly light on processing power.
>>
>> I also thought is_in:* was to be discouraged. Being hard coding, if
>> a boundary was to change all affected entities would become
>> inaccurate.
> 
> Yes, if possible always draw boundaries. They are more precise and easier
> to maintain. is_in is unnecessary.
> 
> Kind regards
> 
> Sarah
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


0x3CBE432B.asc
Description: application/pgp-keys
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Nicolás Alvarez
Wouldn't that lead to "mapping for the geocoder"? I'm sure that would
be frowned upon as much as "mapping for the renderer".

-- 
Nicolás

2016-08-16 16:50 GMT-03:00 Hakuch :
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one
>
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
>> On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
>>> Hi
>>>
>>> I've heard a claim from a user who still wants to use the is_in:*
>>> tag as well as boundary tags that Nominatim uses is_in as preference
>>> because "geospacial mathematics is resource intensive".
>>>
>>> Is this true?
>>
>> Not at all. Nominatim happily processes boundaries and always prefers
>> it over any other hierarchy information.
>>
>> It is true that it still understands is_in:* tags but prbably not in
>> the way you would think. First of all, they are completely ignored
>> on anything at building level (e.g address points and POIs). For
>> everything else Nominatim always uses a geospatial match when
>> computing the address. is_in:* is just good to help make a decision
>> when there are two equally well suited candidates, generally when, say,
>> a road is right between two city place nodes. As soon as there are
>> boundaries, multiple candidates don't happen anymore, so that is_in:*
>> is ignored for all practical purposes.
>>
>>> I thought geospacial calculations were fairly light on processing power.
>>>
>>> I also thought is_in:* was to be discouraged. Being hard coding, if
>>> a boundary was to change all affected entities would become
>>> inaccurate.
>>
>> Yes, if possible always draw boundaries. They are more precise and easier
>> to maintain. is_in is unnecessary.
>>
>> Kind regards
>>
>> Sarah

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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Sarah Hoffmann
On Tue, Aug 16, 2016 at 09:50:05PM +0200, Hakuch wrote:
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one

Not really. You can have a look at the presentation I gave at SOTM
Birmingham[1] but it's a bit dated and not really something where you
'look up' these things.

Sarah

[1] http://osm.lonvia.de/presentations/2013-nominatim.html

> 
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
> > On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> >> Hi
> >>
> >> I've heard a claim from a user who still wants to use the is_in:*
> >> tag as well as boundary tags that Nominatim uses is_in as preference
> >> because "geospacial mathematics is resource intensive".
> >>
> >> Is this true?
> > 
> > Not at all. Nominatim happily processes boundaries and always prefers
> > it over any other hierarchy information.
> > 
> > It is true that it still understands is_in:* tags but prbably not in
> > the way you would think. First of all, they are completely ignored
> > on anything at building level (e.g address points and POIs). For
> > everything else Nominatim always uses a geospatial match when
> > computing the address. is_in:* is just good to help make a decision
> > when there are two equally well suited candidates, generally when, say,
> > a road is right between two city place nodes. As soon as there are
> > boundaries, multiple candidates don't happen anymore, so that is_in:*
> > is ignored for all practical purposes.
> > 
> >> I thought geospacial calculations were fairly light on processing power.
> >>
> >> I also thought is_in:* was to be discouraged. Being hard coding, if
> >> a boundary was to change all affected entities would become
> >> inaccurate.
> > 
> > Yes, if possible always draw boundaries. They are more precise and easier
> > to maintain. is_in is unnecessary.
> > 
> > Kind regards
> > 
> > Sarah
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> > 

> pub  4096R/3CBE432B 2015-09-17 Hakuch 
> sub  4096R/77F3A4C3 2015-09-17 [expires: 2016-09-16]

> ___
> 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] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Dave F


On 16/08/2016 21:35, Nicolás Alvarez wrote:

Wouldn't that lead to "mapping for the geocoder"? I'm sure that would
be frowned upon as much as "mapping for the renderer".


All tags are 'mapping for the renderer/geocoder/router. Otherwise you 
have just black lines, lots of 'You are here' signs stacked on top of 
each other & vehicles going round in circles.


Tagging *incorrectly* to suit the above is what's frowned upon.

Dave F.

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


[OSM-talk] Fwd: Invitation: OSM Analytics Roadmap Chat

2016-08-16 Thread Cristiano Giovando
Hey fellow mappers,

Some of you already know and have been using OSM Analytics since its
launch in April [0], but for those who are not familiar with it,
here's the direct link http://osm-analytics.org

This was initially a small prototype project, but given the interest
and feedback by many in the OSM community, we're now thinking how to
scale it and include more functionalities.

To start the discussion around a roadmap, we are holding a public
community chat this Thursday, August 18th, at 17:00UTC [1] on Gitter:
https://gitter.im/hotosm/osm-analytics

Everyone is welcome to join - I think we will have some more technical
discussions on the infrastructure design, but also less technical ones
about feature requests and ideas for new functions.

All OSMA code is public here [2]. Would be great to also discuss how
to integrate other OSM applications that focus on statistics, quality
assurance, user analytics and validation into OSMA and vice-versa. One
example is this work [3] by Jennings Anderson, built on a similar
processing workflow/stack, that has lots of great insights and
visualizations on OSM contributors and data quality.

If you are around on Thursday, we'd love you to join and share your
ideas. See you then!

Cristiano


[0] 
https://hotosm.org/updates/2016-04-28_explore_how_the_world_is_mapped_with_osm_analytics

[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+Analytics+Roadmap+Chat&iso=20160818T17&p1=1440&ah=1

[2] https://github.com/hotosm/osm-analytics

[3] http://mapbox.github.io/osm-analysis-collab/osm-quality.html


-- 
Cristiano Giovando
Humanitarian OpenStreetMap Team
cristiano.giova...@hotosm.org
http://www.hotosm.org

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


[OSM-talk] Spoken street names

2016-08-16 Thread Nick Hocking
Is there any navigation software (for a Mobile phone) that uses offline OSM
data and also has spoken street names?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Spoken street names

2016-08-16 Thread Hans De Kryger
OsmAnd
http://osmand.net/


Scout
http://www.telenav.com/products/scout/

*Regards,*

*Hans*

On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking 
wrote:

> Is there any navigation software (for a Mobile phone) that uses offline
> OSM data and also has spoken street names?
>
> ___
> 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] Spoken street names

2016-08-16 Thread Rodrigo Rodríguez
Speakig of that, I have MAPS.ME installed on my Android and it's
supposed the app has a voice navigation system but it doesn't work. Any
thoughts on that?

Regards,


On 16/08/16 23:03, Hans De Kryger wrote:
> OsmAnd
> http://osmand.net/
>
>
> Scout
> http://www.telenav.com/products/scout/
>
> *Regards,**
> *
> *Hans*
>
> On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking  > wrote:
>
> Is there any navigation software (for a Mobile phone) that uses
> offline OSM data and also has spoken street names?
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-- 
Rodrigo Rodríguez
http://mundonomada.info
__
La rebeldíⒶ siempre sirve.

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


Re: [OSM-talk] Spoken street names

2016-08-16 Thread Hans De Kryger
*Regards,*

*Hans*

On Tue, Aug 16, 2016 at 10:13 PM, Rodrigo Rodríguez  wrote:

> Speakig of that, I have MAPS.ME installed on my Android and it's supposed
> the app has a voice navigation system but it doesn't work. Any thoughts on
> that?
>
> Regards,
>

​It just tells you where to turn, sadly it doesn't tell you the name of the
street. Hopefully they add that soon.​


>
> On 16/08/16 23:03, Hans De Kryger wrote:
>
> OsmAnd
> http://osmand.net/
>
>
> Scout
> http://www.telenav.com/products/scout/
>
> *Regards,*
> *Hans*
>
> On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking 
> wrote:
>
>> Is there any navigation software (for a Mobile phone) that uses offline
>> OSM data and also has spoken street names?
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
> --
> Rodrigo Rodríguezhttp://mundonomada.info
> __
> La rebeldíⒶ siempre sirve.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk