Oops did not send this to the group<br><br>Dale<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Dale Puch</b> <span dir="ltr"><<a href="mailto:dale.puch@gmail.com">dale.puch@gmail.com</a>></span><br>
Date: Wed, Apr 7, 2010 at 11:59 PM<br>Subject: Re: [Talk-us] Street Naming Conventions<br>To: andrzej zaborowski <<a href="mailto:balrogg@gmail.com">balrogg@gmail.com</a>><br><br><br>In my explanation of what I think would be best the comma separated examples are only to show how the 4 fields would be broken into different tags, not as 4 items in a single tag.<br>
All streets that use them would have tags something like name_directional: name_prefix: name: and name_suffix: with all data spelled out in full.<br>
<br><div class="gmail_quote">As far as the tiger data being in separate tags, yea that is the basic 
idea.  It is there because Dave preserved the tiger fields as best he 
could.  But these are not standard tags that OSM apps use for names.  If we moved to the 4 tag method then the tiger tags could be deleted (or converted to the new ones).<br><br>Of course the less drastic approach is to just make the name: tag complete without any abbreviations.  And could also be a stepping stone to the 4 tag method at any later date.<br>

<br>Dale<div><div></div><div class="h5"><br>
<br>On Wed, Apr 7, 2010 at 7:09 PM, andrzej zaborowski <span dir="ltr"><<a href="mailto:balrogg@gmail.com" target="_blank">balrogg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>On 8 April 2010 00:13, Dale Puch <<a href="mailto:dale.puch@gmail.com" target="_blank">dale.puch@gmail.com</a>> wrote:<br>
> Personally I like the 3 field, or event the 4 field storage of the name.<br>
> Yes that means there is not a single field that has the full name, but I do<br>
> not think a lookup and concat of 4 fields vs 1 field is much different in an<br>
> indexed database.  Perhaps a DB admin can shed some light on the best<br>
> approach from a design and system resources standpoint.<br>
><br>
> This may be a problem for apps, but if it is the best way to manage the<br>
> data, the apps just need to be changed.  And it would not be that hard to<br>
> make the programming change if I can figure out how to do it with my limited<br>
> knowledge.<br>
><br>
> Some of the examples comma separated into the 4 field format:<br>
> South, ,1000 East, Street<br>
> ,State, Park, Street<br>
> ,Saint, Tropez, Street<br>
<br>
</div>Paul Johnson mentioned on IRC today the case of East Doctor Martin<br>
Luther King, Junior Boulevard, which wouldn't work with this schema<br>
and I don't even want to imagine how the schema would be adapted to<br>
the 200 other languages used in the database :)  I think the tag like<br>
name= should really be consistent so tools can rely on it without<br>
adapting to every single country.  As for the different segments of<br>
the name, there are already fields for them which we inherited from<br>
TIGER, you'll find the "middle" of the name is unmodified in the<br>
tiger:base_name= tag, the cardinal direction in<br>
tiger:directional_prefix= and tiger:directional_suffix and the feature<br>
type (Street, Ave etc) in type:name_type.<br>
<br>
Cheers<br>
</blockquote></div></div></div><br><br clear="all"><br>-- <br><font color="#888888">Dale Puch<br>
</font></div><br><br clear="all"><br>-- <br>Dale Puch<br>