Page Comparison

...

First, let's look at a small example xml fragment.
Here is an xml fragment from the existing eas change notification (as of 2011.09.15).

<base_address>
    ...
    <street_name>PINE</street_name>
    <street_name_suffix>
        <abbreviated>ST</abbreviated>
        <unabbreviated>STREET</unabbreviated>
    </street_name_suffix>
    ...
</base_address>

As you can see this will not support aliases.

The simplest thing that could possibly work would be...
Also DPW is starting

<base_address>
    ...
    <StreetSegment>
        <Primary>
            <street_name>MISSION BAY SOUTH</street_name>
            <street_name_suffix>
                <abbreviated>BLVD</abbreviated>
                <unabbreviated>BOULEVARD</unabbreviated>
            </street_name_suffix>
        </Primary>
        <Alias>
            <street_name>MISSION BAY SOUTH BLVD</street_name>
            <street_name_suffix>
                <abbreviated></abbreviated>
                <unabbreviated></unabbreviated>
            </street_name_suffix>
        </Alias>
        <!-- more aliases here -->
    <StreetSegment>
    ...
</base_address>

This approach accomplishes our immediate goals. Should we do this? I still find myself leaning towards leaving the message format as is and changing the consumer over to use EAS IDs for the updates. However, if you feel strongly that we need aliases in the message I can add them. I do not think it will be expensive to do so - may be an hour - possibly less.

Now, the bigger picture...

DPW has already started work to add pre and post direction next week.
to the street names. This would be the "SOUTH" in "MISSION BAY BLVD SOUTH". I will be meeting Eddy at DPW tomorrow and DPW Fri Sept 16 to discuss this as well as other issues. Of utmost importance is that EAS does not break with the DPW changes. If we are forced to make changes, what I describe below should provide us a good starting point.

As always I will push for the FGDC modelfollowing with FGDC standards wherever it is reasonable.
For far too much information on the FGDC see:
http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address
I have found this documemnt documment to contain about the right amount of information:
http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/AddressStandardFINAL.zip

What does this look like?
Here is a fragment for CompleteStreetName that follows the FGDC postal address standard final draft.

<CompleteStreetName>
    <StreetNamePreModifier></StreetNamePreModifier>
    <StreetNamePreDirectional></StreetNamePreDirectional>
    <StreetNamePreType></StreetNamePreType>
    <StreetName>MISSION BAY</StreetName>
    <StreetNamePostType>BLVD</StreetNamePostType>
    <StreetNamePostDirectional>NORTH</StreetNamePostDirectional>
    <StreetNamePostModifier></StreetNamePostModifier>
</CompleteStreetName>

And here is what I think we may need for right nowthese immediate DPW changes.

<CompleteStreetName>
    <StreetNamePreDirectional></StreetNamePreDirectional>
    <StreetName>MISSION BAY</StreetName>
    <StreetNamePostType>BLVD</StreetNamePostType>
    <StreetNamePostDirectional>NORTH</StreetNamePostDirectional>
</CompleteStreetName>

If we add aliases to Expanding on this in the context of the change notification,
and we were starting from scratch I would go this routewe might end up with something like this ...

<base_address>
    ...
    <StreetSegment>
        <StreetSegmentId>12345</StreetSegmentId>
        <StreetNames>
            <Primary>
                <CompleteStreetName>
                    <StreetNamePreDirectional></StreetNamePreDirectional>
                    <StreetName>MISSION BAY NORTH</StreetName>
                    <StreetNamePostType>BLVD</StreetNamePostType>
                    <StreetNamePostDirectional></StreetNamePostDirectional>
                </CompleteStreetName>
                <StreetNamePostTypes>
                    <abbreviated>BLVD</abbreviated>
                    <unabbreviated>BOULEVARD</unabbreviated>
                </StreetNamePostTypes>
            </Primary>
            <Alias>
                <CompleteStreetName>
                    <StreetNamePreDirectional></StreetNamePreDirectional>
                    <StreetName>MISSION BAY BLVD NORTH</StreetName>
                    <StreetNamePostType></StreetNamePostType>
                    <StreetNamePostDirectional></StreetNamePostDirectional>
                </CompleteStreetName>
                <StreetNamePostTypes>
                    <abbreviated></abbreviated>
                    <unabbreviated></unabbreviated>
                </StreetNamePostTypes>
            </Alias>
            <!-- additional aliases here -->
        </StreetNames>
    </StreetSegment>
    ...
</base_address>

This approach

• insluates us from impending changes at DPW
• supports alias
• supports various suffixes
• trys to follow the FGDC standard

However, a more concise appraoch would be...

<base_address>
    ...
    <StreetSegment>
        <Primary>
            <street_name>MISSION BAY SOUTH</street_name>
            <street_name_suffix>
                <abbreviated>BLVD</abbreviated>
                <unabbreviated>BOULEVARD</unabbreviated>
            </street_name_suffix>
        </Primary>
        <Alias>
            <street_name>MISSION BAY SOUTH BLVD</street_name>
            <street_name_suffix>
                <abbreviated></abbreviated>
                <unabbreviated></unabbreviated>
            </street_name_suffix>
        </Alias>
    <StreetSegment>
    ...
</base_address>

This simpler approach accomplishes our immediate goals.
I'll be talking to DPW tomorrow to see if we must to make changes in EAS
to prevent breakage when they make changes StreetNamePreDirectional and StreetNamePostDirectional

...