Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-05 Thread Nathan Edgars II


Nic Roets wrote:
> 
> On Tue, Oct 5, 2010 at 2:00 AM, Shaun McDonald
>  wrote:
>> On 5 Oct 2010, at 00:38, Nic Roets wrote:
>>> The biggest problem I experience when searching with Nominatim for a
>>> street is that you need to guess the place name that *it* has chosen.
>>> For example, Hyperion Drive falls in a suburb (johannesburg North, I
>>> think). The suburb falls in a region and the region falls in a city.
>>> And the city falls in a province. Some of that information is already
>>> in OSM as administrative borders.
>>
>> Admin, town and city boundaries are in many ways hit and miss with
>> nominatim, however that is generally through a lack of osm data. Or
>> better said just having points, where it is difficult to estimate the
>> size. For example according to Nominatim Surrey covers most of London
>> http://nominatim.openstreetmap.org/details.php?place_id=559111 (Which it
>> doesn't really). By using Polygons for the boundaries in the osm data
>> instead of simple points, it will be more likely to give a more accurate
>> result.
>>
> 
> That's a nice visual presentation. I guess it's generated by Fortune's
> algorithm like Brian mentioned on dev.
> 
> The first problem with trying to get polygons for all places is that
> surveying them can be quite labourious, if not impossible.
> 

Polygons won't solve the whole problem. For example, I have an Orlando
address, yet I'm in unincorporated Orange County, outside the city limits.
Probably the only way is to find matches near the city center (node if
present, else polygon centroid) and sort by distance, after somehow
eliminating duplicates (streets split into multiple ways).

A couple examples:
Della Drive, Orlando, Florida: All the results come out as being in "Dr.
Phillips, Edgewood, Orange County, 32819, Florida, United States of
America". Dr. Phillips is correct (it's the neighborhood) but Edgewood is a
city with a polygon about 6 miles to the east.
Ruby Lake Road, Vineland, Florida: no results (despite Vineland having a
polygon that Ruby Lake Road is inside), nor with any other nearby cities or
unincorporated communities; only Ruby Lake Road, Orange County, Florida
seems to work
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/OSM-and-MapQuest-was-Hurricane-hits-MapQuest-tp561p5602170.html
Sent from the General Discussion mailing list archive at Nabble.com.

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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-05 Thread Shaun McDonald

On 5 Oct 2010, at 08:26, Ed Avis wrote:

> Shaun McDonald  shaunmcdonald.me.uk> writes:
> 
>> For example according to Nominatim Surrey covers most of London
>> http://nominatim.openstreetmap.org/details.php?place_id=559111
> 
> Is there a reason why Nominatim doesn't use the administrative county 
> boundaries?
> 

Do you have an example of one in the osm data that it doesn't use?

Shaun


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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-05 Thread Ed Avis
Shaun McDonald  shaunmcdonald.me.uk> writes:

>For example according to Nominatim Surrey covers most of London
>http://nominatim.openstreetmap.org/details.php?place_id=559111

Is there a reason why Nominatim doesn't use the administrative county 
boundaries?

-- 
Ed Avis 


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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-05 Thread Nic Roets
On Tue, Oct 5, 2010 at 2:00 AM, Shaun McDonald
 wrote:
>
> On 5 Oct 2010, at 00:38, Nic Roets wrote:
>
>> On Tue, Oct 5, 2010 at 12:46 AM, Ed Avis  wrote:
>>> So, is it possible for Mapquest to generate aggregate information on what 
>>> name
>>> searches people are doing and how often they find the result they wanted?  
>>> The
>>> latter is not something you can measure directly, but you can see which of 
>>> the
>>> offered results the user clicks on, which gives a clue.
>>
>> The biggest problem I experience when searching with Nominatim for a
>> street is that you need to guess the place name that *it* has chosen.
>> For example, Hyperion Drive falls in a suburb (johannesburg North, I
>> think). The suburb falls in a region and the region falls in a city.
>> And the city falls in a province. Some of that information is already
>> in OSM as administrative borders.
>>
>> But end users seldom know where the borders are, so they will just
>> search for "hyperion, johannesburg" and not get an answer. (To get it,
>> search for "hyperion, roodepoort") Or they will be too lazy to type
>> the suburb.
>
> Admin, town and city boundaries are in many ways hit and miss with nominatim, 
> however that is generally through a lack of osm data. Or better said just 
> having points, where it is difficult to estimate the size. For example 
> according to Nominatim Surrey covers most of London 
> http://nominatim.openstreetmap.org/details.php?place_id=559111 (Which it 
> doesn't really). By using Polygons for the boundaries in the osm data instead 
> of simple points, it will be more likely to give a more accurate result.
>

That's a nice visual presentation. I guess it's generated by Fortune's
algorithm like Brian mentioned on dev.

The first problem with trying to get polygons for all places is that
surveying them can be quite labourious, if not impossible.

The second problem is that people, especially tourists and foreign,
don't speak like that. They often know only one placename, like
Johannesburg
http://nominatim.openstreetmap.org/details.php?place_id=750446

IMHO, Gosmore handles the problem a little bit better: It first finds
the placename and then it will look for occurrences of the street
name, even if they are quite far from the place.

> Another problem is that place names can be fuzzy, as one person will say 
> place x will cover a certain area, however another person will say it covers 
> a different area, yet officially that's wrong.
>
> Shaun
>
>

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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-04 Thread Ævar Arnfjörð Bjarmason
On Mon, Oct 4, 2010 at 23:28, Frederik Ramm  wrote:
> Hi,
>
> Ed Avis wrote:
>>
>> In general, I think our goal must be to make OSM a suitable replacement
>> for
>> Google Maps, and to do so as quickly as possible.
>
> [...]
>
>> So we need to find a
>> way to prioritize our efforts
>
> -1 on both. Not saying that you mustn't prioritize your efforts - by all
> means do! - but "we"?

We the people in this project who are interested in mapping things
that people are looking for, if you want to prioritize differently
that's fine.

But as the Haiti effort shows there's lots of people here willing to
work on areas that have a clear need expressed by a lot of people.

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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-04 Thread Shaun McDonald

On 5 Oct 2010, at 00:38, Nic Roets wrote:

> On Tue, Oct 5, 2010 at 12:46 AM, Ed Avis  wrote:
>> So, is it possible for Mapquest to generate aggregate information on what 
>> name
>> searches people are doing and how often they find the result they wanted?  
>> The
>> latter is not something you can measure directly, but you can see which of 
>> the
>> offered results the user clicks on, which gives a clue.
> 
> The biggest problem I experience when searching with Nominatim for a
> street is that you need to guess the place name that *it* has chosen.
> For example, Hyperion Drive falls in a suburb (johannesburg North, I
> think). The suburb falls in a region and the region falls in a city.
> And the city falls in a province. Some of that information is already
> in OSM as administrative borders.
> 
> But end users seldom know where the borders are, so they will just
> search for "hyperion, johannesburg" and not get an answer. (To get it,
> search for "hyperion, roodepoort") Or they will be too lazy to type
> the suburb.

Admin, town and city boundaries are in many ways hit and miss with nominatim, 
however that is generally through a lack of osm data. Or better said just 
having points, where it is difficult to estimate the size. For example 
according to Nominatim Surrey covers most of London 
http://nominatim.openstreetmap.org/details.php?place_id=559111 (Which it 
doesn't really). By using Polygons for the boundaries in the osm data instead 
of simple points, it will be more likely to give a more accurate result.

Another problem is that place names can be fuzzy, as one person will say place 
x will cover a certain area, however another person will say it covers a 
different area, yet officially that's wrong.

Shaun


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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-04 Thread Nic Roets
On Tue, Oct 5, 2010 at 12:46 AM, Ed Avis  wrote:
> So, is it possible for Mapquest to generate aggregate information on what name
> searches people are doing and how often they find the result they wanted?  The
> latter is not something you can measure directly, but you can see which of the
> offered results the user clicks on, which gives a clue.

The biggest problem I experience when searching with Nominatim for a
street is that you need to guess the place name that *it* has chosen.
For example, Hyperion Drive falls in a suburb (johannesburg North, I
think). The suburb falls in a region and the region falls in a city.
And the city falls in a province. Some of that information is already
in OSM as administrative borders.

But end users seldom know where the borders are, so they will just
search for "hyperion, johannesburg" and not get an answer. (To get it,
search for "hyperion, roodepoort") Or they will be too lazy to type
the suburb.

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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-04 Thread Frederik Ramm

Hi,

Ed Avis wrote:

In general, I think our goal must be to make OSM a suitable replacement for
Google Maps, and to do so as quickly as possible. 


[...]


So we need to find a
way to prioritize our efforts


-1 on both. Not saying that you mustn't prioritize your efforts - by all 
means do! - but "we"?


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [OSM-talk] OSM and MapQuest [was Hurricane hits MapQuest]

2010-10-04 Thread Ed Avis
Coast, Hurricane  mapquest.com> writes:

>>are there any
>>particular wishes from the Mapquest people about how the data can be
>>improved?
>
>>We do have a wish list that I'm sure is quite similar to many OSMers. But
>>let me turn around the question to the community: how do you think the data
>>can be improved? Where should we, collaboratively, start?

I think one of the first things you notice when trying to use OSM (be it osm.org
or Mapquest) instead of Google Maps is the search function.  The hit rate is not
great.  Some of this will require code fixes to Nominatim but at least as much
will be due to missing data, or perhaps because of inconsistent tagging of the
data we have.

So, is it possible for Mapquest to generate aggregate information on what name
searches people are doing and how often they find the result they wanted?  The
latter is not something you can measure directly, but you can see which of the
offered results the user clicks on, which gives a clue.

In general, I think our goal must be to make OSM a suitable replacement for
Google Maps, and to do so as quickly as possible.  However getting 100% coverage
is not something we can achieve in the short term, especially in countries with
no additional sources of data besides individual mappers.  So we need to find a
way to prioritize our efforts on the 80% most useful part of the map.  Some
search statistics would provide a way to do that.

-- 
Ed Avis 


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