[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J Busser
Subject: Re: [Gnumed-devel] Questions re database schema:street:address:urb:country
Date: Tue, 7 Sep 2004 00:42:40 -0700

 > 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, 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]