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

[Karsten Hilbert]

> In town A it may be named Lakeshore Road
> 
> As one leaves town A, the roadway may be named Highway 1A
> (e.g. a "scenic" alternate to highway 1)
> People may reside along this roadway!
> 
> Crossing into town B the roadway may still bear the name Lakeshore 
> Road. In truth - - - e.g. because town B residents have sloped views 
> and higher property values - - - the roadway might be called Lakeside 
> Drive ;-)  but we will assume Lakeshore Road for this example and 
> assume some other patient in the practice has already been registered 
> as living on Lakeshore Road in town A.
This is not really of concern to us, I tend to believe. For
all the GnuMed backend knows these are two "streets". Sometime
later, when we want to ask questions like "can an ambulance
get to Smith' home without crossing Bluewater Bridge ?" this
may become relevant. But by then the GIS derivative of FEBRL
will answer that question.

> When asking/entering/editing a new patient's address, they will 
> typically say "I live at 2155 Lakeshore".
> 
> We would presumably skip the 2155 initially in order to input 
> Lakeshore, and observe (based on an existing value)  we can ask the 
> patient:
> "That's Lakeshore here in town A right?" and the patient could say
> "No, I'm on Lakeshore over in town B" and if this combination did not 
> yet exist, the user would, after inputting 2155 Lakeshore, advance 
> into the URB field where they might easily be offered town B because 
> there are patients from town B in the practice - - - they just don't 
> live on Lakeshore Road.
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.

> Existing street/urb combinations would save us having to bother 
> inputting the state (or, in Canada, the "Province") code and the 
> country code which could be derived automatically from street/urb.
Right.

> I am not sure whether free databases are reliably available to offer 
> valid postcodes for our patients' street addresses. Still, we *could* 
> pick postcodes from existing values for street/urb combinations in 
> the practice or, if these are unsuitable, the user can add one.
We would automatically be building one. One of my silent hopes
is to eventually put code into GnuMed that sends such
anonymous street/urb/state/country etc mappings back to a
central GnuMed repository so that future versions can
come with improved initial datasets.

> In the example of Lakeshore above, if the roadway should ever be 
> renamed, the change would likely only occur at the URB level i.e. one 
> URB  has no authority to change the roadway's name outside of its URB 
> boundaries. There exist super- (regional) authorities which sometimes 
> rename major connecting roadways (such as highways) but in this case, 
> the name could be updated for each of the affected road "segments" 
> across multiple affected URBs.
Right. For all we care they are three different "streets". It
is just too much typing to always use "stretch_of_passageway".

> Now within an URB - - - e.g. within town A - - - a roadway *could* 
> have more than one segment e.g. where a road curves, or bends, or 
> becomes angled at an intersection. Each segment may have its own 
> name. Across segments, the numbering of the buildings could simply 
> continue, or the numbering could abruptly change to match the 
> adjacent streets, or to respect a north-south or east-west "divide". 
> This seems just a case of each segment being able to be treated as a 
> separate "street", each traveling through only a portion of the town.
Again, we would treat these as separate streets. After all,
that's what the patient's address is.

> I remain foggy on how OPERATIONALLY to use suburbs. In my URB of 
> Vancouver, names "like" suburbs are used to describe or define:
> - the distribution of community centres
> - elementary and secondary school catchment/eligibility boundaries
> - voting districts (municipal, provincial, federal and these are 
> non-identical)
> - real estate administration...
> 
> The above uses do not all share a single set of names / boundaries!
Never mind. I would input into street.suburb whatever people
tell me they live in. If that doesn't match anything else -
tough luck - it was worth a try. People tend to use the same
names for suburbs when it comes to where they live - at least
here in Germany.

> We might be most interested in health-related usage for example the 
> City is divided into "health units" again a problem as these do not 
> match the traditional suburb names or boundaries.
I would use what people naturally use. Such artifical mappings
can always be done by a link table associating address rows
with organizational_region rows.

> Maybe the biggest problem:  suburb boundaries 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.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346