﻿id summary reporter owner description type status priority milestone component version severity resolution keywords cc 678 POI classification tryagain KaZeR "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: {{{ ITEM(traffic_sign_city_limit) ITEM_CLASSIFIED(poi_tree,poi_class_landfeature) }}} 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. " enhancement/feature request closed major version 1.0 core git master wontfix POI