Re: [Gnumed-devel] Demographics schema - urb postcode not null

[Sebastian Hilbert]

On Saturday 08 October 2011 03:07:47 Jim Busser wrote:

While I won't comment on nullable or not keep in mind that postcodes are 
usefull for statistics and calculations (e.g. look up a distance or route on 
google maps). BTW. How often do you input a postcode. Once ?
It will even be imported automatically most of the time.

I guess it would make sense to define unknown as value so this can be searched 
for and updated later.

Sebastian

> v17?
> 
>       relax constraint on dem.urb needing dem.urb.postcode not null?
> 
> can we also (with a post-release client 1.x update) remove, from the
> client, the requirement to input a postal code?
> 
> ps if in psql you do
> 
>       select d_u.name, d_u.postcode, d_st.name from dem.urb d_u
>       inner join dem.state d_st
>       on d_u.id_state = d_st.id
>       where d_u.name = 'Leipzig' ;
> 
> yields
> 
>         name   | postcode |  name
>       ---------+----------+---------
>        Leipzig | 04318    | Sachsen
>        Leipzig | 04317    | Sachsen
>       (2 rows)
> 
> -- Jim
> 
> On 2011-10-07, at 4:40 PM, Karsten Hilbert wrote:
> > Too late for GNUmed-next.
> > 
> > Karsten
> > 
> > 
> > -------- Original-Nachricht --------
> > 
> >> Datum: Fri, 07 Oct 2011 16:28:24 -0700
> >> Von: Jim Busser <address@hidden>
> >> An: GNUmed list <address@hidden>
> >> Betreff: Re: [Gnumed-devel] Demographics schema - urb postcode not null
> >> 
> >> it is both possible (and apparently a notorious problem in some US
> >> states) that you can have two towns or cities which are known by the
> >> same name, despite being located in the same state or province, for
> >> example as
> >> 
> >> documented here:
> >>    http://talk.collegeconfidential.com/parent-cafe/770966-why-do-some-
stat
> >>    es-have-two-towns-same-name.html
> >>    http://answers.yahoo.com/question/index?qid=20080731135833AAfaZFR
> >>    http://en.wikipedia.org/wiki/Middletown,_Pennsylvania
> >> 
> >> This means that when a person would select a street, even the
> >> combination of
> >> 
> >>    street name, dem.urb.name
> >> 
> >> does not (unambiguously) confer on the street any geographic meaning.
> >> 
> >> I recognize it is possible that you could force a user to choose
> >> 
> >>    which Mountain View, California or
> >>    which Middletown, Pennsylvania
> >> 
> >> from a list of two or more, but I continue to have a hard time with the
> >> idea that a city (which may have multiple postal or zip codes) has a
> >> 'default'. Removal of the requirement for postcode from urb would lose
> >> nothing presently because
> >> 
> >> 1) a city has no single (granular) location, it has a bounded area
> >> 2) it has potentially multiple postcodes
> >> 3) it is really only at the level of the street address that we achieve
> >> anything close to a point location. For the purposes of delivering mail
> >> or packages or sending an ambulance to get a patient, we need the
> >> granularity of what is in their address anyway and presently the client
> >> enforces the requirement to provide a postcode at the level of street
> >> (when inputting an address).
> >> 
> >> What this relaxation would then also achieve is to not have to choose
> >> which among
> >> 
> >>    multiple cities of same name in same state or province
> >> 
> >> because the city name is serving only as a crude grouping term, and you
> >> could always select patients of interest by their
> >> required-to-be-inputted street-level postcode or zip.
> >> 
> >> 
> >> If you do not want to relax the constraint on dem.urb.postcode, then how
> >> about to relax the 1.0 client which presently requires to input a
> >> postcode at the level of address / street, reasons being:
> >> 
> >> 1) the backend does not demand a street level postcode
> >> 2) I personally rarely send letter mail to patients, and so forcing me
> >> to input postcodes is extra work for minimal gain
> >> 3) if I later needed the postcode to send something to the patient, I
> >> could look it up
> >> 
> >> -- Jim
> >> 
> >> 
> >> _______________________________________________
> >> Gnumed-devel mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/gnumed-devel
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel