Add suburb information

[nathan-muir]

Related to #30 - In Australia addresses primarily use Suburb over City - addresses are usually in the format:

5 StreetName StreetType
Suburb State Postcode

City represents administrative zones that are not often used or seen.

So - please consider making the suburb field available in the resulting API response.

[lonvia]

Adding more fields is not going to scale because we end up with dozens of different requests for local tagging quirks. The way to go here is to localize the exports on a country level, e.g. for Australian addresses put the suburb info in the city field.

[christophlingg]

thanks for your feedback @nathan-muir and letting us know what Australian users expect.

we could go for @lonvia's approach but we would return suburbs in a city field which does not sound correct to me...? A new field would not lead to an additional request in photon (probably in nominatim it would). As long as data storage is not increased significantly, a new field sounds so be the best option.

Some investigation will be necessary to check what is best.

[nathan-muir]

@christophlingg An extra field sounds good.

It does look a bit fuzzy between "city" and "suburb" in the list of administrative levels- http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Indexing.2Faddress_calculation

It's difficult to decide what would be a reasonable subset of those levels for searching / display.

[amnesia7]

@christophlingg is this the type of thing that the address-formatting project is trying to resolve (location-specific address formatting)?

[avently]

@christophlingg What do you think about including country's ISO code in search results?

[christophlingg]

@avently what's your motivation?

[avently]

For now, I will not use Photon. It doesn't fit my needs. You made it for large search specific projects but I need only small amount of features. So I made my own thing based on my instance of orientdb and self-extracted data from planet.osm using postgis and node.

[phibo23]

I'd like a country code in the results, too. At one point I'm converting the results into our own model classes and our address format requires a country code. Mapping all the localized country strings to iso codes myself seems unnecessarily complicated from my point of view, because the codes are already present in nominatim.

[christophlingg]

So far, country code was not needed. I did not include it in the index as it would store the same information twice in the index, having 100 million entries this would cost some disk space.

Anyway, probably it would not be that much of an impact.

[maraev]

Christoph, is it possible to merge my index of Switzerland with your 31Gb
photon_data?
How can I add or remove any indeces to it?

2015-06-25 18:54 GMT+03:00 Christoph Lingg [email protected]:

So far, country code was not needed. I did not include it in the index as
it would store the same information twice in the index, having 100
million entries this would cost some disk space.

Anyway, probably it would not be that much of an impact.

—
Reply to this email directly or view it on GitHub
#161 (comment).

Best Regards!
Andrey Maraev

[christophlingg]

@maraev I am not 100% sure what you are about to do. Maybe you can merge two elasticsearch indices (probably some elasticsearch experts can help you with that). As my global index also contains swiss data you need also remove duplicate entries i guess.

[maraev]

I used the photon instruction and got my Photon_data from Nominatim, but
now I see that your offer
http://photon.komoot.de/data/photon_data_021_150112.tar.bz2 index of
Germany,France Italy and England. So, I thought that I could be unit my
photon_data and your.
Anyway, Would you be able to explain how I can use photon_data with
elasticsearch engine? As I can see photon also provide es port 9200

2015-06-26 16:48 GMT+03:00 Christoph Lingg [email protected]:

@maraev https://github.com/maraev I am not 100% sure what you are about
to do. Maybe you can merge two elasticsearch indices (probably some
elasticsearch experts can help you with that). As my global index also
contains swiss data you need also remove duplicate entries i guess.

—
Reply to this email directly or view it on GitHub
#161 (comment).

Best Regards!
Andrey Maraev

[christophlingg]

the dump is actually world wide, not only the contries you mentioned.

photon is based upon elastic search, that's why you can access elasticsearch via port 9200

[maraev]

Thanks for your help. I'll certainly try use it.

2015-06-26 17:18 GMT+03:00 Christoph Lingg [email protected]:

the dump is actually world wide, not only the contries you mentioned.

photon is based upon elastic search, that's why you can access
elasticsearch via port 9200

—
Reply to this email directly or view it on GitHub
#161 (comment).

Best Regards!
Andrey Maraev

[sroycode]

For those interested, I created a tag on my fork that handles locality.
https://github.com/sroycode/photon

A new field "locality" added : comprising {"hamlet", "neighbourhood", "suburb", "village"} and layer-15 elements, "city" has been limited to {"city", "county", "town" }
The motivation was data in India, where

• city tag is mostly absent even for data in cities
• the hamlet or village mentions locality name

Examples:
http://nominatim.openstreetmap.org/details.php?place_id=2569344337
http://nominatim.openstreetmap.org/details.php?place_id=100649805

[cammanderson]

Hi Guys,

I realise that I am writing about an old issue. I'd like to +1 the support for hamlet/neighbourhood/suburb/village being sourced as the locality.

City values aren't being populated for Australian addresses, so it addresses to the entire region of Australia, which will be rejected by postal services as they can't differentiate "14 High Street" from the 50 main streets that exist in the region.
This happens in multiple countries so not isolated to a single region (named here including Australia and India).

The suggestion by @sroycode looks reasonable, as a lot of results are missing even the city. There is no reasonable inclusion and must maintain a separate fork (which is now 3 years out of date) to get a workable address result to Australia/India.

Can we please re-open and consider the business cases here?

[hbruch]

As this issue discusses a range of topics, I'd rather suggest to open a new issue.

Could you have a look into PR #303? With the additions @gopi-ar proposed, might this solve your issue? On the other hand, @lonvia proposed to make country-specific adaptations, like e.g. @hendrikmoree proposed via PR #346. I'm not sure if we should favour one above the other or both (or three, if we reconsider locality) are valid on their one?

And could you provide some testcases to the geocoders/geocoder-test project describing your expected behaviour?

[hendrikmoree]

Hi @hbruch ,

Adding suburb won't work for the Netherlands. The problem is that the suburb in Nominatim isn't always the city name in the Netherlands. For example in Amsterdam (Suburb is North instead of Amsterdam), but for this example the city is Bennekom and this is correct and Ede isn't.

There's no way using Nominatim to find the correct city name in the Netherlands. The only one that's always correct is taking admin level 10

[sroycode]

You can please have a look at https://github.com/sroycode/zapdos , where the data input can be made country specific.
This is mainly to bring a simple solution to map location typeahead since current versions of Elasticsearch no longer support embedding .