Re: [Gnumed-devel] Questions re database schema:street:address:urb:country

[J Busser]

>  > Crossing into town B the roadway may still bear the name Lakeshore
>  > Road.
> This is not really of concern to us, I tend to believe. For
> all the GnuMed backend knows these are two "streets".

I was just setting a scenario where town B can choose to (re-)name 
its "portion" of a street that continues across its boundary, and 
that this name could later change again e.g. in honor of some local 
person, without giving Gnumed trouble the way the backend has been 
set up.

>  > When asking/entering/editing a new patient's address, they will
>  > typically say "I live at 2155 Lakeshore".
> Why would they be offered town B ? The only reason I can see
> would be that *most* patients of this practice live in B. If
> the system doesn't know there's a Lakeshore Rd in B (due to
> having other patients there) it won't know to offer B here.

If you mean "why would they be offered a lakeshore / Town B" combo I 
agree, "no" if the combo did not already exist.

But if you mean "why offer Town B" at all even when "Lakeshore / Town 
B" has still to be created for the first time? As a user keys in 
"Lakeshore" the closest match be "Lakeshore Road / Town A" but that 
is no good. The user will want to signal "yes, street.name truly is 
Lakeshore Road, but not Town A" --- a new row will need to be created 
for this street name (even thogh the street name may already exist) 
because a different urb will need to be designated from among 
existing entries in the urb table *or* from a new entry.

One's own local urb can always be offered as the default, but just 
because most patients live in Town A should not mean that I can't be 
offered Town B and Town C if they are already in the system. 
Vancouver is only 12km x 20km and is bordered by 4 other "Towns" with 
many people getting medical care across these boundaries. Even if 
some other Gnumedder lives in isolation, or with a "pure" local 
practice with 99% of their patients from a single urb, that gnumedder 
will, when inputting addresses, be inputting other urbs for the 
addresses of organizations and visiting patients.

I note also in the street table some "unique" constraints on each of 
id_urb,  name and postcode but is is the *combination* that is 
unique? A Canadian postal code specifies to the level of one or two 
city blocks, either the "even" side or "odd" side of the street which 
means that within the same town, a street that runs the length of the 
city could have (I am just guessing here) 30 or 40 postal codes and 
so would result in 30 or 40 rows in the table, yes?

When inputting a patient's address I would be happy for a phrase 
wheel to narrow down the matches especially after I type several 
letters of the street and a few letters of the city. However if the 
user can only pick from fixed combinations of street/urb/postcode, 
this may be painful: even when the street/urb combinations already 
exist, the postcodes will often not. May there be some way for the 
user to accept the match on the street/urb portion (to save having to 
re-key it), but to indicate that a new row will be required to hold a 
new postcode?

>  > I remain foggy on how OPERATIONALLY to use suburbs...
>  > tend to be defined by
>  > road and street intersections such as 1st avenue through 16th avenue
> >  between Burrard St and MacDonald St. This may correspond to a range
> >  of street building addresses, and a range of postal codes, yet
> >  whichever administrative body defined the boundaries would not have
> >  mapped them to specific ranges of addresses or postal codes.
> I don't think we need to worry about that. We are providing
> added value, not necessities here.

Sort of what I thought... suburb seems like it can be used "loosely", 
for whatever function it seems to best serve,  in those settings 
where "suburb" may not be tightly coupled to precise physical 
addresses.