Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#678 closed enhancement/feature request (wontfix)

POI classification

Reported by: tryagain Owned by: KaZeR
Priority: major Milestone: version 1.0
Component: core Version: git master
Severity: Keywords: POI


Now we have two code parts where each POI item should be defined: in item_def.h and in gui_internal (see struct_selector selectors[]).

The latter is needed to divide POI into categories and seems to be out of date now: some new POI types were added to attr_def.h but not described in gui_internal.

Keeping POI classification array in gui_internal.c is bad idea because:

  • classification should be usable in other GUI types.
  • it's not so easy to maintain consistency with item_def.h

So I think POI classification mechanics should be redesigned.

As usual, we have multiple ways to do it.

1. item.[ch] easily can be adopted to support both current ITEM macro and additional syntax of ITEM_CLASSIFIED for type description, then probable extract from attr_def.h could look like this:


Everybody who is going to append a new item type will see that he can classify that new item. But I bet there should exist some regional POI usage practices which can make hardcoded POI classification not so usable.

2. POI types can be defined in navit.xml (actually, I'd made it in file included to navit.xml with xi:include). This way we can have hierarchical classification like banks\offices and banks\ATMs. Some POIs can be included into several classes (don't have example where it will be usable but sure it will be).

Second variant seems to be less easy to maintain (after adding POI to item_def.h we should add its classification to xml file).

Of course, possible solutions do not end with these two.

Change History (3)

comment:1 Changed 6 years ago by korrosa

  • Summary changed from POI calssification to POI classification

comment:2 Changed 4 years ago by usul

  • Resolution set to wontfix
  • Status changed from new to closed

Personally I don't think that this is a wise idea, because it mixes different aspects:

  • data storage format
  • data representation

Of course I understand your POV and appreciate your interest in reducing redundancy. But a single POI type can have very different meanings, depending on the map you try to design, so a hard classification might be less flexible.

As there was no feedback since years, I close this case. But feel free to reopen it anytime if there is a need for discussing this idea. I recommend to use the forum for such kind of discs:

comment:3 Changed 4 years ago by sleske

I agree with usul. At the moment, the POI classification is only used in the internal GUI, so it makes sense to keep it there. Once other parts of the code also need it, we can think about generalizing it.

Note: See TracTickets for help on using tickets.