Jody,
"The procedure for an unsupported module remains the same..."
OK. I figured it didn't hurt to bounce things off of the list. You
never know what someone else is working on.
Jody wrote: "my question
is how tied to north america your address structure will be?"
This is a good question, and I have already been thinking about it.
The ESRI data model for Addresses actually deals with French and
American style street addresses because it was built for the City of
Calgary. I could try to make my code as "nation" nuetral as possible,
but I will only be using it on my project in the US. I worry about
complicating the code to an unecessary level to support different
types of street address systems. I don't mind using "postal code"
instead of "zip code" or "region" instead of "state" and "province",
but I don't know that I want to worry about some funky address system
used in Sudan where an address is related to the distance from the
nearest oasis. I'd like to make my code abstract enough for use by
others, but I don't want to get ridiculous.
Jody wrote: "If you
could review the OpenLS specification (which has the best run at
"Address" I have found) and get back to me on what you think?"
Every where I look there is an OGC spec. :]
You know I'm not particularly fond of OGC standards, but I took a look
at the spec, and I think I could use the Address ADT as my XML
backing. I'm not sure if you had more support for the standard in
mind.
Jody wrote: "Many of the other topics you mention (parsing an address)
are actually
a significant RnD topic for anyone who makes a geocoder. My best
advice is to focus on data rather than parser; indeed if you have all
the addresses in a database prior to parsing you will be able to
handle this much better using the ideas of "searching" rather than
"parsing"."
My parsing needs are simple. I want to take a typical US street address like:
711 North Pershing Avenue, Stockton, CA 95206
and create an object that implements the following type of interface:
public interface UnitedStatesRouteAddress extends RouteAddress
{
public int getStreetNumber();
public boolean isRouteDirectionAvailable();
public StreetDirection getRouteDirection();
public String getRouteName();
public boolean isRouteTypeAvailable();
public String getRouteType();
public String getMunicipalityName();
public State getRegion();
public int getPostalCode();
}
I'm not worried at all about geodcoding in the low-level library. I've
got good land parcel data and can find the address for each land
parcel. In OpenJUMP I'm going to associate each land parcel feature
with one or more address instances using something like a RDBMS
relationship.
So I won't be cooking up a geocoder for this exercise.
Then I'll write some code that does something like this:
public class RouteAddressQueryFrontEnd
{
public List<RouteAddress> getAddressesInMunicipailty(String
argMunicipailtyName, List<RouteAddress> argTarget);
public List<RouteAddress> getAddressesInRegion(String
argMunicipalityName, List<RouteAddress> argTarget);
public List<RouteAddress> getAddressesInPostalCode(Int argPostalCode,
List<RouteAddress> argTarget);
}
The RouteAddressQueryFrontEnd will call an underlying query engine
that supports pluggable queries:
public interface RouteAddressQueryEngine
{
public List<RouteAddress> executeQuery(RouteAddressQuery argQuery);
}
where the RouteAddressQuery is simply a list of filter objects.
In OpenJUMP, at a high-level in the code, I will be doing something like this:
public class SelectParcelByAddressPlugIn extends PlugIn
{
public void selectParcelsWithAddress(RouteAddress argAddress, Layer argTarget);
}
but this code won't go into the Geotools module, because it will need
OpenJUMP architecture.
I hope this makes sense. This is still taking shape in my mind, and
may change as I get more familiar with the needs of my particular
project.
Landon
On Tue, Apr 14, 2009 at 4:01 PM, Jody Garnett <[email protected]> wrote:
> The procedure for an unsupported module remains the same; my question
> is how tied to north america your address structure will be? If you
> could review the OpenLS specification (which has the best run at
> "Address" I have found) and get back to me on what you think?
>
> Many of the other topics you mention (parsing an address) are actually
> a significant RnD topic for anyone who makes a geocoder. My best
> advice is to focus on data rather than parser; indeed if you have all
> the addresses in a database prior to parsing you will be able to
> handle this much better using the ideas of "searching" rather than
> "parsing".
>
> Cheers,
> Jody
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
