...
EAS Field: address_base.base_address_num (int)
XML Field: base_address/base_number
FGDC Field: address number (int)
AVS Field: AVS_ADDRESSES.STREET_NUMBER (NUMBER 6)
Example:
Comment:
*****
EAS Field: address_base.base_address_suffix (char 10)
XML Field: base_address/base_number_suffix
FGDC Field: address number suffix (text)
AVS Field: AVS_ADDRESSES.STREET_NUMBER_SFX (VARCHAR2 1)
Example: "1/2"
Comment: MAD-122
TODO: widen AVS fieldresolve column width issue
Discussion
The issue here is that widening the AVS column would trigger significant changes in many parts of DBIs systems.
Moreover, much of that work would be tossed out when they adopt the new permitting system within 1-2 years.
Here are the alternatives
1) Change the AVS column to char 10.
As stated above, this will be expensive and the ROI will be low.
2) Column definitions stay the same in both systems...and in the interface between the systems use only the first character from the EAS field.
This will cause problem with uniqueness because "100 1 Main St" would equal "100 1/2 Main St".
3) Change EAS so that it allows only 1 character in this field.
This would work as an interim solution with the following caveats.
It is moving us in the wrong direction - away from a well know standard (FGDC).
When someone wants to create something like "100 1/2 Main St" we won't be able to support it properly.
4) Column definitions stay the same in both systems...
In the interface between the systems, we convert the EAS char 10 field into a single unique "lookup character" and use that character in the interface.
In this solution, the interface would convert "100 1/2 Main St" to "100 â Main St" where the "â" character is
- arbitrary
- generated by the interface
- will not collide with the existing ascii characters (0-127) in this field thereby supporting uniqueness properly
AVS would store the single character and displays it in the UI in the usual way.
The AVS databse will have to be able to support the insertion of unicode characters (encoding of UTF-8 or equivalent).
The downside of this solution is that for the "â" to be meaningful, the user must take an extra step look up the address.
We can easily provide that service, but the non-meaningful character is a a violation of a number of UI design principals.
The existence of addresses with legitimate street number suffixes is relatively rare.
Therefore, I would anticipate that operational issues here will be a lack of familiarity of this kind of address and how to look it up, etc.
On the other hand, I think any char 1 solution here is going to have this problem.
This is because street number suffix could be "1" or "A" or "1A" or whatever.
5) change the column width in AVS but do not change the forms and reports
Val is looking at this possible solution.
There may be the equivalent of compiler errors that prevent us from going down this path.
EAS Field: address_base.geometry.longitude (double)
XML Field: base_address/longitude
FGDC Field: address longitude (double)
AVS Field:
Example:
Comment:
...