Use facc code to determine feature type name in VPF

Jeff Yutzler added a comment - 28/Feb/05 6:17 PM John Meagher wrote: >Based on requests from my users I've made some changes to the >VPFFeatureType to base the feature type name on the facc code of the >feature type. The updated source file and supporting properties file >for this are attached. Everything else appears to work unchanged. > >This represents a minor code change but a pretty major change in how VPF >works so I wanted to run it by you guys before checking it into the >geotools repository. Here's how I changed the feature type name: > > - Base the feature type name on the name of the facc code using a >property file lookup to determine the "name" > > - Surround the auto-attached Area/Line/Point/Text with parenthesis > > - Don't capitalize the type name or replace spaces and punctuation with >"_". This one I'm particularly worried about as this may have been done >due to some other limitation that I'm not aware of. > The fact that this issue exists at all shows the distinct difference between VPF users and other GIS users. If the data in a VPF dataset is considered to be VPF data, then referring to the feature types by their FACC code is obviously the way to go. However, if it is just data, that just so happens to be stored in VPF, the FACC code is basically meaningless. While AP030 or GB005 means something to a VPF user, it is just a random five character sequence for someone who is not familiar with VPF. From the perspective of my users, the data is only useful if someone can figure out what it is. Picture a scenario where a user looking for road layers examines the capabilities of a WFS that just so happens to be serving VPF data. The user needs a way to discover which layer is likely to be the one they want and a FACC code does not help here. For this reason, I am reluctant to completely abandon the original mechanism. Since I understand the value of the FACC codes to your users, I recommend allowing both mechanisms and using a configuration item to determine which will be used. By the way, the capitalization and underscore replacements were solely to facilitate the use of SQL to access them. If only capital letters and underscores are used, the strings do not need to be quoted. This behavior is not mandatory.

John Meagher added a comment - 01/Mar/05 8:56 AM Actually this does not expose the FACC code to the user. Instead it uses a property file lookup to decode the FACC code into a feature type name. To illustrate a few lines from the property file are included below: Facc.BC098.name=Navigational Mark, Afloat Facc.BC098.description=Complex feature with possible components made of many simple features only. Facc.BC099.name=Navigational Mark, Fixed Facc.BC099.description=Complex feature with possible components made of many simple features only. Facc.BE021.name=Drying Line, Low Water Line-LWL Facc.BE021.description=Delineates an area that covers and uncovers depending on the elevation of the surface above chart datum. The FACC name from the property file is used as the feature type name. If the FACC name lookup fails for any reason the feature type name falls back to the old convention.

John Meagher added a comment - 12/Apr/05 9:50 AM I think I described the problem poorly initially. The real problem is that the feature type that's requested from the data store does not match the feature type that's contained in the features that are actually returned. As an example if you request "Depth Curve (Area)" as the feature type the feature type on the returned features will be something like "hdrarea". Instead the type of the features should match the requested feature type.

Michael Bedward added a comment - 24/May/10 10:33 PM VPF module no longer supported