Re: [Libosmscout-development] add feature to address type

[Tim T. <ti...@fr...>]

Hello Stephan,

I'm a little bit lost between Mailinglist Usernames and GitHub  
Usernames (Who is who?).

The merged pull request  
https://github.com/Framstag/libosmscout/pull/112 IMHO did it right. It  
is yours? Most of the stuff here is also contained in above pull  
request. If it is not yours, please try to coordinate your efforts.  
Does not make any sense, to implement the zip code feature twice.

For the "why so and not different" aspect I'll comment anyway.

> i also haven't given up on creating a new Type POSTCODE and a  
> PostcodeFeature/PostcodeFeatureValue.
>  so i can have :
>
>   TYPE postcode
>     = NODE AREA (EXISTS "addr:postcode")
>       POSTCODE

There is IMHO no need for a POSTCODE qualifier. ADDRESS is enough. If  
an object "holds" an address it will likely have a postcode tags, too,  
if mapped.

So assigning a Postcode feature to any type that has the ADDRESS  
qualifier, should be enough.

> so far i have copied all address related stuff and made it for postcode.
> it is quite alot and overview is hard if not to say impossible to  
> track what is needed.
> As is said i have a PostcodeFeature/Value/Reader and a type in  
> typeconfig for the postcode.

That sounds OK. The feature holds the "metadata" of the feature. The  
Values the concrete value for any object having the feature. The  
Reader like some other templates are just simple helper classes for  
several types of features.

> Also i have extended the Place to get Postcode.
> I have also extended the GenAreaArea  and GenLocationIndex for the import.
> I am nor sure how this :
>
>         scanner.Read(location);
>         scanner.Read(address);
>         scanner.Read(postcode);

> can know how to find a postcode or address in GenLocationIndex.cpp???
> I guess the actual "Data" of an address is stored in areaaddress.dat  
> and nodeaddress.dat???

Yes. The GenXXX classes (now) read the postcode, write it into the  
temporary data files and clear the feature (since the actual feature  
and its value or not required anymore normally after the import is  
finished).

> My goal was to have a location with postcode even if the location  
> has no "address" which is actual a housenumber.

This could be discussed. But lets see how it works out.

> But the actual location indexes are stored all together in location.idx?
> So i need a new lets say "AREAPOSTCODE_DAT" and "NODEPOSTCODE_DAT"
> for the postcode data in the GenAreaAreaIndex and GenLocationIndex??

The patch just extended the existing files. No need to keep that separate.

> I was able to build the whole lib and import a map , but when i try  
> to get a "Place" it says : "Position beyond file end"
> So i guess something is messed up with the locationindexes?!

Your broke the file format. Read and Write of data does not match  
anymore. You are trying to read beyond the end of the file.

> What is the actual difference between a type and a feature??

An object can have exactly one type. The type is the main filter for  
the style sheet. A types though can have multiple features. Matching  
it to a programming language: The type is the class, the features are  
its attributes. feature values the attribute values of an concrete  
instance.

What is currently missing:
* Currently features are indexed. So a feature always cost a bit for  
each object instance, even if it is not set. Sometimes you want to  
assign to a type any amount of features, but you just want to iterate  
over them. Things of some sport arena. You can do a large amount of  
sport (football, basketball,...)in it. You could of course for each  
variant of sport arenas define a new type. This will get problematic,  
if there are multiple kinds of sport in one arena. In this case you  
one to enumerate them all as part of a feature value and later on  
iterate over them in the style sheet to e.g. drawn an icon for each of  
them. This is currently not possible or at least not efficient in its  
definition.

> Do i really need a type or can't i just use a new feature to be able to get
> place.GetPostcode() beside with place.GetAddress() ???

A feature is enough. The Address type is just a fallback in cases  
where you just have a node with an address without any other type.  
This is for example the case if a building has multiple addresses. In  
this case the area for the building is of type building. In the area  
multiple nodes are places and they have only address data. These will  
be catched by the Address type. If you automatically assign the  
Postalcode feature to any type with the ADDRESS category everything  
will be fine.

See the patch above for the current state. Please use this  
mailinglist, the patch chat for further synchronisation.
-- 
Gruß...
    Tim