Full address search (city+street+housenumber) for the Netherlands

[Harry van der Wolf]

Hi,

This Dutch address OBF contains (theoretically) ALL(!) addresses in
Nederland. They are stored as node.

Note that this is something completely different from the "Nationwide
address maps for large countries"
(https://groups.google.com/forum/#!topic/osmand/C-Aojwp5F8U). These
are address maps for the large countries containing the standard OSM
addresses.
Maybe the next version of this Dutch address map will have another
name like Netherlands_full_address or so (suggestions?).

The past 1½ week I dived into BAG (Basisregistraties Adressen en
Gebouwen), which is a completely open service (CC-BY-SA-3.0) from the
Dutch Kadaster. See also the BAG viewer at
http://bagviewer.geodan.nl/index.html (on the opening page simply
click "Akkoord"). I downloaded the addresses DB (1.3GB) (from
http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml)
and created the database from it (24GB).

It contains all panden (houses) and adressen (addresses) in Nederland.
It's update monthly or 3-monthly. I don't know yet as they have many
(thematic) downloads which are regularly updated.

==How to use it ==
- Download the zip and unpack it in your osmand folder on your phone/tablet
- In OsmAnd goto Search -> Address Search (the house icon)
- Select the "Netherlands address" map
- Search your city/street/housenumber
- After finding use "Show on map" or "Set as destination".
- OsmAnd will automatically use the Netherlands map to display the
location. This does mean that you need the normal Netherlands map to
navigate and display. Maybe I will later offer a Dutch navigation map
with the OSM address part removed and the BAG adress part inserted.

= Note that searching the smaller villages/hamlets, which are not
directly indexed, can take long as the OBF is so big.
= Note also that some (not all) streets are mentioned double if they
move from one district/suburb to another. Sometimes the addresses
occur twice, sometimes only in one of the suburbs. I will investigate
that further.
= Note also that this maps contains addresses of streets not even
realised, but destined for future building. A district in my
neighbourhood only contains 3 houses yet, but all addresses are
already mapped.


You can download the Netherlands_address_2.obf.zip (temporarily?) from
my public dropbox osmand folder:
https://dl.dropboxusercontent.com/u/34701986/Osmand/Netherlands_address_2.obf.zip

It's a 167MB zip and unpacked 550MB.


Harry

[Ar Age]

Wow Harry, this is a major usability improvement of OSMand! It works great! Thanks!

Cheers,

Rene

Op zondag 8 september 2013 10:10:33 UTC+2 schreef Harry van der Wolf:

[Andre]

Amazing!

Thanks very much Harry.  It works fine,  is rather fast for such a big file,  and compact too,  knowing there are nearly 9 million 9.000.000 addresses in the Netherlands.
Very very good work!  This file makes Osmand an absolute killer app for offline address search in the Netherlands.  There is no other solution on Android so complete,  usable and precise. Party!

Andre.oid

Op 8 sep. 2013 10:10 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andre]

Hi Harry,

I wonder if there is also a way to display the house numbers on the map as a text.  Or would the file then be a lot bigger?

Op 8 sep. 2013 11:07 schreef "Andre" <andreo...@gmail.com> het volgende:

[Harry van der Wolf]

2013/9/8 Andre <andreo...@gmail.com>

Hi Harry,

I wonder if there is also a way to display the house numbers on the map as a text.  Or would the file then be a lot bigger?

I didn't think of that stupid enough. I ran OsmAndMapCreator only with the address index on. I justed started a rerun where I index the map as well. Let's see. But it will take 4-5 hours.

Harry

[Andre]

Great!

Op 8 sep. 2013 12:56 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Harry van der Wolf]

I also put the scripts on my public Osmand dropbox folder.

Anyone who is interested can have a look: https://dl.dropboxusercontent.com/u/34701986/Osmand/adres_scripts.zip

Harry

2013/9/8 Andre <andreo...@gmail.com>

[Andre]

Hi Harry,

Maybe it's an idea to request that the small villages are indexed also because it takes some time and cpu indeed .  I don't know if that requires a change in the obf format or map creator. 

Op 8 sep. 2013 13:09 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Pee Wee]

Harry

What took you so long?  More then 1 week from idea to full implementation. I hope you'll speed things up in the future.  ;-)

Seriously: What a great job done. I think that for NL this is the first app to pinpoint every house/building. I'll do some more investigation and will get back to you via PM.

Thanks a lot.

Cheers PeeWee32

[Harry van der Wolf]

It's missing Baarle-Nassau and Baarle-Hertog. Maybe because they are multipolygons having Belgian holes inside. I will take a look at it.

[Harry van der Wolf]

Going from large to small we have cities, towns, villages, hamlets, etc.

Only the cities and towns are indexed. It will require a change to OsmAndMapCreator but I have no idea what it will do to the overal perfomance when looking for cities/towns/villages, etc.

Harry

[Andre]

Harry,

I noticed that you also created house numbers with alpha chars,  like 24B. They are even well sorted!
But I think they should be created with a space between.  At least there are very few numbers that have a number like 27-1. Look for instance at Biddinghuizen,  Bremerbergdijk 27-1,  27-2 and so on.  They are around the harbor near number 27.
There should be also a number 33, but I cannot find it.  You can find it in Google,  and in Locus,  who uses the Google search API for addresses,  and which is rather good, ( al be it not as good as BAG.)  By the way,  I think we should include this online API in Osmand,  to be used by all others that are not as lucky to live in Holland.  It also allows to search on names like restaurants.

Op 8 sep. 2013 10:10 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Harry van der Wolf]

The adres table is built up like (among others): huisnummer, huisletter, huisnummertoevoeging.

I simply concat them together.
The database doesn't make a difference in 27A, 27 A or 27-A.

I will add a space between the huisnummer and huisletter the next time.

Harry

2013/9/8 Andre <andreo...@gmail.com>

[Andre]

Or you can add a - before the huisnummer toevoeging,  in that case the 27-1 issue is solved too.

Op 8 sep. 2013 18:55 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Harry van der Wolf]

Yes,but that would not solve it for other addreses as most cities do it differently. Here in Zwolle we even have 1 G1, 1 G2, 1G3 in flats. And some houses have 11A and 11B (without space)

If I put a dash in between it would be incorrect for those addresses.

I don't care that much, as everyone understands it (and if they don't understand it they shouldn't be driving a car), but I would like to fit the most occuring combi's.

I don't know yet which combi that is: space, dash or nothing.

It's OK with me to put a dash in, especially to prevent the error with 27-1 or 127, but I will look a little further if I can analyze this or not.

Harry

2013/9/8 Andre <andreo...@gmail.com>

[Andre]

I think if it has a number and toevoeging,  but not a huisletter,  you could use the dash,  and not in other cases. 

Op 8 sep. 2013 19:25 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Harry van der Wolf]

This is easier said then done. Maybe you have seen the queries.

One of them:
select xmlelement(name node, xmlattributes(nummeraanduiding as id, 'true' as visible, ST_X(ST_Transform(geopunt, 4326)) as lon, ST_Y(ST_Transform(geopunt,4326)) as lat, '1' as version)), xmlelement(name tag,xmlattributes('addr:street' as k, openbareruimtenaam as v)), xmlelement(name tag,xmlattributes('addr:housenumber' as k, ARRAY_TO_STRING(ARRAY[huisnummer::text, huisletter, huisnummertoevoeging], '') as v)), xmlelement(name tag,xmlattributes('addr:postcode' as k, postcode as v)), xmlelement(name tag,xmlattributes('addr:city' as k, woonplaatsnaam as v)),xmlelement(name node_end) FROM adres where woonplaatsnaam like 'A%' order by woonplaatsnaam,openbareruimtenaam;

The "ARRAY_TO_STRING(ARRAY[huisnummer::text, huisletter, huisnummertoevoeging], '') as v"  is the one doing the current work.

The sql is not a problem but this would require some pl/sql programming which is at least 15 years ago for me.

I can not simply add a "-" because if a housenumber doesn't have "extra's" you would get 1-, 2-, 3- and you certainly don't want that. I need to build in some intelligence there.

That's why I wanted to add a space. You don' t see that if nothing follows it (and I try to be as lazy as possible)

Harry

2013/9/8 Andre <andreo...@gmail.com>

[Harry van der Wolf]

The "ARRAY_TO_STRING(ARRAY[huisnummer::text, huisletter, huisnummertoevoeging], '') as v" is actually very smart. I have now nothing as separator and if I use a dash like "ARRAY_TO_STRING(ARRAY[huisnummer::text, huisletter, huisnummertoevoeging], '-') as v", it works fine. It doesn't put a separator when there is no need for a separator (well, I never touched postgresql before, only since last Sunday so learning every hour).

 <node id="193200000003893" visible="true" lon="6.11879571447816" lat="52.5154830341527" version="1"/> | <tag k="addr:street" v="Aagje Dekenstraat"/> | <tag k="addr:housenumber" v="29"/>     | <tag k="addr:postcode" v="8023BZ"/> | <tag k="addr:city" v="Zwolle"/> | <node_end/> <node id="193200000003894" visible="true" lon="6.11859520413318" lat="52.5153875820359" version="1"/> | <tag k="addr:street" v="Aagje Dekenstraat"/> | <tag k="addr:housenumber" v="25-G-7"/> | <tag k="addr:postcode" v="8023BZ"/> | <tag k="addr:city" v="Zwolle"/> | <node_end/> <node id="193200000003895" visible="true" lon="6.11843867476785" lat="52.5157210887327" version="1"/> | <tag k="addr:street" v="Aagje Dekenstraat"/> | <tag k="addr:housenumber" v="37-G-7"/> | <tag k="addr:postcode" v="8023BZ"/> | <tag k="addr:city" v="Zwolle"/> | <node_end/> <node id="193200000007727" visible="true" lon="6.11912573100579" lat="52.514820219931" version="1"/>  | <tag k="addr:street" v="Aagje Dekenstraat"/> | <tag k="addr:housenumber" v="6"/>      | <tag k="addr:postcode" v="8023BX"/> | <tag k="addr:city" v="Zwolle"/> | <node_end/>

So a dash '-'  it will be.

Harry

[Andre]

You are a genius!

Op 8 sep. 2013 19:54 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

--

[Harry van der Wolf]

I uploaded a new version that displays the numbers also on the map (with the normal Netherlands map "below" it). It has grown from 550MB to 687MB. It took a bit longer as I needed to assign 6GB for map creation where I had 4GB and 5GB first.

I renamed the zip as well and removed the first one.

The new one is https://dl.dropboxusercontent.com/u/34701986/Osmand/Netherlands_address_2.obf-20130908.zip

Note: it's only with number display on the map. Other maps with the number improvements and some errors removed (Baarle-Nassau of Baarle-Hertog, missing numbers 1-74 Koedijk) will take longer. 

The current run is creating a map with dashes between the numbers, but that will also take some hours.

Being the release manager of Hugin, I need to do an RC2 release tomorrow, so map updates will need to wait a little longer.

Harry

2013/9/8 Harry van der Wolf <hvd...@gmail.com>

[Andre]

Great.  I will test it.  With numbers displayed that only would be easier.

[Andre]

Wow... This is fun. Looks great.
No need for OSM in netherlands to discuss a few years more about how to implement addresses. Not talking about the enormous job to integrate the house numbers into relations with buildings and streets. Lets post some nice comment on the osm nl talk list :-)

I can see the house numbers on kanaaldijk 1-73 now too. Not sure how to search them though. I can't find them in Koedijk, neither in Alkmaar but somehow they are there. According to Google they are in Koedijk. Wished they were clickable!. But then they have to be pois, and that will make the obf file even bigger I guess. Not sure how much bigger, and if it slows down search performance. Would be great even better maybe,  because we can see the complete address then, including the zipcode or postcode when clicking on the orange poi symbol.
Searching by postcode works also now on every postcode I tried till now! Then the streetnames in the postcode are shown.  Try 1060NN ! Cool. After choosing the street you can't choose from a list of housenumbers, but that is no big problem because you can see the housenumbers on the map.
Very nice functionality! 

Andre.oid

Op 8 sep. 2013 22:20 schreef "Andre" <andreo...@gmail.com> het volgende:

[Harry van der Wolf]

Hi,

2013/9/8 Andre <andreo...@gmail.com>

Wow... This is fun. Looks great.
No need for OSM in netherlands to discuss a few years more about how to implement addresses. Not talking about the enormous job to integrate the house numbers into relations with buildings and streets. Lets post some nice comment on the osm nl talk list :-)

I'm not on this list, but go ahead.

I can see the house numbers on kanaaldijk 1-73 now too. Not sure how to search them though. I can't find them in Koedijk, neither in Alkmaar but somehow they are there. According to Google they are in Koedijk. Wished they were clickable!. But then they have to be pois, and that will make the obf file even bigger I guess. Not sure how much bigger, and if it slows down search performance. Would be great even better maybe,  because we can see the complete address then, including the zipcode or postcode when clicking on the orange poi symbol.

That was one of my other "side goals": To make it into a poi database. Having the data available only requires a little rewrite of the scripts.
But how to store the POIs for later retrieval?
By streetname + housenumber? That would result in a massive amount of Dorpstraat 6 or Hoofdstraat 22 or so.
Or city + streetname + housenumber? That would make it inconvenient to search.

Next to that:  POI search works by searching within 100 kilometers and then extending.

I think it should be a "user defined" POI as well.

Harry

[Harry van der Wolf]

Hi,

I uploaded the third one. I uploaded it this morning but it took some time for whatever reason.
This one contains the dashes ('-') between the complex addresses so that you won't find 271 where it should be 27-1.

Check my public dropbox Osmand folder: https://www.dropbox.com/sh/6hbu1sbfwy6pel6/WStvZZKb8t/Osmand

It has grown again due to these dashes which also come from "gebruiksdoelverblijfsobject", category "overige verblijfsfunctie".

More on that during my lunch break :)

Harry

[Andre]

Hi,

Strange enough the display on the map is allright with numbers like 27-2 or 2 B, but the address selection form displays it as a calculator :-)
e.g. 27-2 (+1)  or 2B(+1) , so with every house number that is followed by a huisletter or toevoeging the number is followed by (+1). Strange... Maybe Victor can explain that?

Andre.oid

Op 10 sep. 2013 09:45 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

[Harry van der Wolf]

2013/9/10 Andre <andreo...@gmail.com>

Hi,

Strange enough the display on the map is allright with numbers like 27-2 or 2 B, but the address selection form displays it as a calculator :-)
e.g. 27-2 (+1)  or 2B(+1) , so with every house number that is followed by a huisletter or toevoeging the number is followed by (+1). Strange... Maybe Victor can explain that?

Andre.oid

I've seen that too. It's not in the osm file, so it must be OsmAndMapCreator. I already checked for doubles (+1 means two equal addresses?), but that's not the case either.

Harry

[Harry van der Wolf]

Hi Dutchies,

sorry: long mail ahead.

I'm in a bit of a squeeze now. I have now created the first and the second adress index, and tonight the third one with '-' between complex numbers/extensions (28-1 instead of 281, and 11-B instead of 11B).

I checked the data a little more.
(And sorry, some of the wording is in Dutch).
The addresses, or actually the "panden" (buildings), can have several purposes (gebruiksdoelverblijfsobject): see (in Dutch) http://www.basisinformatie-amsterdam.nl/doku.php?id=inwinnen:bag:inwinnen-bag:introductie:gebruik.
Most of them are just fine, but it's the "overige gebruiksfunctie" that bothers me. It contains "garagebox, parkeergarage, gemaal, waterzuivering, watertoren, gasdistributiestation, stroomdistributiestation, drinkwaterpompstation, trafo, windmolen, overig energie en water, telefooncentrale, stationsgebouw".

We can do without all those entries except perhaps from parkeergarage and stationsgebouw (although some are just adjacent buildings). I can filter on "overige gebruiksfunctie" and I think it will reduce the address OBF by 1-3% based on some premature investigations. But I can't filter inside the "overige gebruiksfunctie".
The "stationsgebouw" is in 100% of the cases already defined in the POIs and you will almost always search on POI instead of e.g. Stationstraat 1 (to give a logical example).
The parkeergarage might have a (much) lower coverage in the POIs, but again, mostly you will search on POI and not on adress. I know quite some parkeergarages by name in my home town but I have only a vague idea about the address and that's only the street. Besides: you don't need them in your home town and in a foreign town you will definitely search by POI.

Apart from the size of the file I would like to get rid of all the schuurtjes (barn, shed, schack, shanty, barrack, choultry (lot of synonyms)) and garageboxes. To me that's all useless information as you will not use that to navigate to. Most of the time you even can't.
Especially in dense living areas with a lot of flats, you often find a "overige gebruiksfunctie" per address for flats that have their own "schuurtje" (storage cell) in the basement per apartment house, or sets of garageboxes. You never want to navigate to such a storage cell (not me at least :) )
Same goes for "gasdistributiestation, stroomdistributiestation, drinkwaterpompstation, trafo, windmolen, overig energie en water, telefooncentrale". That might only be of use for specialist workers. It's not in Navigon or Tomtom either.
We would get rid of addresses like 1-G-1, 2-G-1 which are almost all (sets of) garageboxes (as far as I checked) and 23-T-1 and so which are most of the time workplace/workshop/workrooms like TNT having an address for the office and a T1 address for the sorting center, or a garage with a main entrance with an address and a workplace T1, or simply one of those "green" electricity distribution houses/boxes in a suburb/district.
Please also check via e.g. bagviewer (http://bagviewer.geodan.nl/index.html) and let me know if I miss something important.

As we are in an open source community your voice also counts: Should I go for the query without "overige verblijfsfunctie"? I think that a smaller map will also be slightly faster and more responsive. Or is it not worth the hassle?
You already know my preference. But on the other hand: If I leave them in it will be the most complete full address search ever, as even Navigon and Tomtom can't find these special addresses :).

I will make at least one map without it (just started it remotely), just to try it and see what it does to the final size. (Just waiting for the scripts/queries to chew away these huge amount of data).

Harry

[Ar Age]

Hi Harry,

I think all buildings you mentioned are just POI's like you said. In general most people won't navigate to such buildings so don't add them to your addresses.obf. Maybe an option might be to create a separate obf file just for those special buildings for people who like to use it e.g. government, police or whatever. Don't know if separate files will work in OSMand though...

Groet

Rene

Op zondag 8 september 2013 10:10:33 UTC+2 schreef Harry van der Wolf:

[Andre]

This needs some analysis.  Some garageboxes have a separate number.  Some have thecsame number as the house they belong to, but followed by a -g (meaning garage). However,  these boxes csn be hundreds of meters from the house. I think until further notice it is ok if they are in the file.  The size will not mather very much. And it is difficult to distinguish between real addresses with 'other purposes'  and infrastructure objects that have an address.  By the way, people working in infrastructure maintenance might be very happy with it. There is nearly no other place to find them.

Andre.oid

Op 10 sep. 2013 12:34 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

--

[Pee Wee]

I'm with Andre. Why bother for such a small %. It will also save you time explaining why some buildings are and others are not searchable.

I've read that it is possible to search for postcode but I can't seem to find out how. Any suggestions?


Cheers PeeWee

Op dinsdag 10 september 2013 19:12:31 UTC+2 schreef Andre Oid:

[Andre]

Put in postcode in the city field.

Andre.oid

Op 10 sep. 2013 20:13 schreef "Pee Wee" <piew...@gmail.com> het volgende:

[Pee Wee]

Op dinsdag 10 september 2013 20:17:41 UTC+2 schreef Andre Oid:

Put in postcode in the city field.

Andre.oid

Thanks. found it. Don't understand what  I did wrong yesterday. Only strange thing is that I can find the PC which then leads to the streetname but after that I do not see any building to pick from. When I don't use PC but type the city for the same street I do get a picklist with buildings.

Cheers PeeWee

[Andre]

Thats right.  Because a street can have many postcodes and a postcode or zipcode can have more streets or part of streets (try 1060NN) , the index should know which numbers belong to each postcode.  That is not the case now. The index only knows which numbers belong to each complete street in a city. If the index should know what you and I would like to see, then the file size should be much bigger.  And who likes that ? Is it worth the file size? That should be a discussion.  Searching and typing can be much faster because less characters needed. In Holland only 6 + 2 or 3 for the house number. Personally I would like it. I have to buy a 64Gb sd card anyway ;-)

Andre.oid

Op 10 sep. 2013 20:46 schreef "Pee Wee" <piew...@gmail.com> het volgende:

--

[Harry van der Wolf]

2013/9/10 Pee Wee <piew...@gmail.com>

I'm with Andre. Why bother for such a small %. It will also save you time explaining why some buildings are and others are not searchable.

It turns out to be less than 1%. Not worth it indeed.

Harry

[Andre]

Don't mind. Never waste the chance of a deliberate decision ; -)

Op 10 sep. 2013 21:48 schreef "Harry van der Wolf" <hvd...@gmail.com> het volgende:

--

[Harry van der Wolf]

Hi all,

I created another address extraction. The huisnummer, huisletter, huisnummertoevoeging is now part of a case statement.

When the huisletter is a digit, the number is split with a space like "27 1', otherwise it is simply concatenated like 11A.

(This has the "simple approach" that WHEN huisletter is null (nothing), it is not a digit so the ELSE clause works and adds a space for anything to come in the huisnummertoevoeging, be it a number or character. For those interested I added the sql.)

There are some weird situations in a couple of cities where the sub-numbers range from 1 to 41, which means that you have numbers ranging from "27 1" to "27 41", but when using dashes, like "27-41", it might even look that it is a range of numbers instead of a number with subnumber.

Primarily I choose for the space instead of a dash ('-') as OsmAnd somehow interprets the dash as a minus sign adding (+1)  and wanting to do a calculation?
I think OsmAnd doesn't do typesetting in outputting a housenumber. Maybe in OsmAnd it is as simple as something like ToString(housenumber). I found "String.valueOf(number)", but maybe that tries to calculate it before outputting it, which would be utterly incorrect (27-1 = 26, or worse 27-41 = -14).

So when this is solved in OsmAnd I might switch for a dash for numbers (again going back to 27-1) and "nothing" for characters.

(And I optimised my "big file" handling with sed which shortens that process from 2½ hours to 15 minutes).

You can find the new Dutch address obf in my public dropbox Osmand folder: https://www.dropbox.com/sh/6hbu1sbfwy6pel6/WStvZZKb8t/Osmand

It's tagged with 20130914.

Hoi,

Harry

 

[Ar Age]

Hi Harry! The address search for Holland is becomming better and better, thanks to you!

I did some testing today and found that " otherwise it is simply concatenated like 11A." like you mentioned is not always true. As in Amsterdam, Kalverstraat you'll see that numbers 28 and 49 do have an extra space like "28 H" or "49 H". It doesn't bother me that much but still...

And is it that important that you want to use a minus "-" between numbers like eg 45-3? Maybe you can use a tilde "~"?

Last but not least, maybe we should rename the search fields "Gebouw" and "Kies gebouw" into "Huisnummer" and "Kies huisnummer" in the Dutch OSMand version?

[Harry van der Wolf]

2013/9/15 Ar Age <ara...@gmail.com>

Hi Harry! The address search for Holland is becomming better and better, thanks to you!

I did some testing today and found that " otherwise it is simply concatenated like 11A." like you mentioned is not always true. As in Amsterdam, Kalverstraat you'll see that numbers 28 and 49 do have an extra space like "28 H" or "49 H". It doesn't bother me that much but still...

It simply means that I have to extend the Case statements a little bit. Obviously it isn't done consequently through the BAG register.

Next run I will enhance the Case statement. In a few days I think.

 

And is it that important that you want to use a minus "-" between numbers like eg 45-3? Maybe you can use a tilde "~"?

Last but not least, maybe we should rename the search fields "Gebouw" and "Kies gebouw" into "Huisnummer" and "Kies huisnummer" in the Dutch OSMand version?

No. it's not that important. It is the most occuring use in the BAG data. That's all.

Harry

[Willie Baltussen]

Hallo,

Ik stel me vraag hier even in Nederlands omdat ik meen dat iedereen die over dit onderwerp gaat ook in Nederland woont.

De vraag:

Waarom zijn bepaalde plaatsen ondergebracht bij andere plaatsen, zoals kleine dorpen die onder een hoofddorp worden gevoegd. Als voorbeeld: familie woont in Leunen (limburg bij Venray), onder de stad is dit niet te vinden (zoekfunctie blijft maar doorlopen als er niet directe een hit is). Als je dan onder Venray gaat zoeken dan vind je de straat wel met tussen haakjes daarachter Leunen. Dat is niet echt praktisch, zeker niet als je ergens onbekend bent en dus geen idee hebt welke hoofdplaats je moet hebben. Idem is overigens ook met Duitsland, dus ligt dit misschien aan osmand?

Op zondag 15 september 2013 17:01:34 UTC+2 schreef Harry van der Wolf:

[Harry van der Wolf]

Hallo,

Het klopt niet wat je zegt.

Als we inderdaad Leunen als voorbeeld nemen, dan komt die niet in de lijst van steden voor. Dat komt omdat de lijst geindexeerd worden op cities/towns. Dat houdt in dat dorpen/gehuchten niet geïndexeerd worden.

Als je Leunen intypt, en dus geen "hit" krijgt, druk je daarna op "Zoek dorp/postcode". Dan zal Leunen (na enige tijd) wel degelijk getoond worden met de straten die daarbij horen.

Als je echter op Venray zoekt, de gemeente waar Leunen bij hoort, krijg je als "extra service" ook de straten (met dorp/gehucht naam daarachter) te zien.

Je krijgt dus juist meer waar voor je geld (en het was toch al gratis).

Harry

2013/11/1 Willie Baltussen <willieb...@gmail.com>

--

[Willie Baltussen]

Dank je voor de snelle reactie,  blijkbaar moet ie de eerste keer heel lang zoeken,  maar inderdaad hij doet. Geweldig dit was net het stukje wat er miste.

Op 1-nov.-2013 14:34 schreef "Harry van der Wolf" <hvd...@gmail.com>:

You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/r_BUIxOQgQY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osmand+un...@googlegroups.com.

[feens...@gmail.com]

Hallo Harry,

ik probeerde de adresfile te downloaden van je dropbox. Deze is echter niet meer aanwezig.
Hoe kan ik aan dit bestand komen?

M.vr.gr.
Klaas Feenstra.

[Harry van der Wolf]

Die heb je ook niet meer nodig. De OsmAnd Nederland map heeft nu zelf alle adressen. Daarom is de file verwijderd van mijn dropbox account.

groet,

Harry

--

You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ernst]

Beste Harry, 

 

Al enkele jaren gebruik ik OSMAND.

 

Had echter problemen om bepaalde adressen te vinden. Bijv. in Blaricum of Badhoevedorp.

 

Ook de NEDERLAND ADRES.obf gaf geen soulaas.

(Maar ik lees in dit forum dat deze niet meer nodig is, omdat alles geintegreerd is in Nederland.obf.)

 

Tot mijn vreugde vond ik vandaag een aanwijzing van jou:

 

=============

---

Dorpsstraat 25 in Lage Vuursche staat er gewoon in.

OsmAnd indexeert alleen de "cities" en "towns". "Villages" en kleiner

worden niet geindexeerd.

Als je dus een dorp of gehucht invult en het verschijnt niet, druk je op

"Zoek verder ( dorp of postcode vinden)". Dan komt Lage Vuursche na enige

tijd tevoorschijn en kun je je adres invullen.

Harry

=================

Zou het niet handig zijn om deze aanwijzing in het manual te zetten?

In ieder geval vooralsnog voor mij opgelost.

Behalve dat:

- deze adres zoekprocedure lang duurt (enige tijd :-) )

- als je het adres probeert te zoeken door op een adres/huisnummer dat in je Android agenda staat te clicken, geeft OSMAND een fout boodschap

Is hier nog ruimte voor verbetering?

Dank.

[Harry van der Wolf]

Hoi Ernst,

Probeer svp je vragen in het engels te stellen. Dit is een engelstalig forum.

Op 10 april 2015 15:38 schreef Ernst <er...@spoor.demon.nl>:

Tot mijn vreugde vond ik vandaag een aanwijzing van jou:

 

=============

---

Dorpsstraat 25 in Lage Vuursche staat er gewoon in.

OsmAnd indexeert alleen de "cities" en "towns". "Villages" en kleiner

worden niet geindexeerd.

Als je dus een dorp of gehucht invult en het verschijnt niet, druk je op

"Zoek verder ( dorp of postcode vinden)". Dan komt Lage Vuursche na enige

tijd tevoorschijn en kun je je adres invullen.

Ik weet niet waar je de verwijzing vandaan haalt, maar die klopt inderdaad. 

Zou het niet handig zijn om deze aanwijzing in het manual te zetten?

Welke manual? Ik weet niet eens dat er één is.

 

In ieder geval vooralsnog voor mij opgelost.

Behalve dat:

- deze adres zoekprocedure lang duurt (enige tijd :-) )

Ja, dat klopt want hij is dus niet geïndexeerd. Dus duurt het zoeken veel langer.

 

- als je het adres probeert te zoeken door op een adres/huisnummer dat in je Android agenda staat te clicken, geeft OSMAND een fout boodschap

OsmAnd houdt zich hier niet aan de regels zoals die vastgelegd zijn door Google voor het sharen van adres gegevens.

 

Is hier nog ruimte voor verbetering?

Zeker weten! 

Ik heb me al eerder beklaagd over het feit dat niet het hele adres bestand geïndexeerd is. Letterlijk alle andere Nav apps doen dat wel. Het heeft volgens mij te maken met het feit dat de index sleutel een integer is ipv een long-integer ofzo. Er kunnen gewoon niet genoeg entries in. Ik heb dat een keer geanalyseerd in OsmandMapCreator en dat doorgegeven aan Victor Scherb, de hoofdprogrammeur, en er daarna niets meer gehoord.

Harry

[Ernst]

Dear All,

albeit a discussion about NL addresses Harry asked me to write in English, because this is an English forum.

In my question I quoted an entry from Harry in this (or another) forum about a functionality that is not obvious, but helpful.

The point is that when searching for an address in the NL map there is not always a result. Even for well know cities (or villages) like Badhoevedorp or Blaricum. Harry's recommendation is to use the button "Continue searching / Zipcode / Villages". Indeed in the said examples this generates a result.

The technical explanation is that the Dutch address database is not indexed. This also explains why the procedure as suggested above is taking some time.

The issue is addressed to the OSMAND head developer, but so far no solution has been provided. (Length of the index key.)

Anyhow, with this suggestion (Dutch) OSMAND users will be very happy.

Reasons why I suggested Harry to add this tip to the manual, or better to the FAQ under the HELP function of OSMAND.

Thanks in advance Harry,

Ernst

Op vrijdag 10 april 2015 15:50:12 UTC+2 schreef Harry van der Wolf: