Lots of weird ones from Florida Many should not give you an issue due to
how your processing, but it is best to test them anyhow. Also it might be
a good reference when looking at other expansions after this runs.
way id=10761946 name v=E 10th Ct E
way id=10763539 name v=E 10th St E
way
On Fri, May 11, 2012 at 11:20 PM, Serge Wroclawski emac...@gmail.com wrote:
W and W Industrial Rd expands to West and W Industrial Road, since
W is the direction_prefix, but the second W is unaccounted for, the
script doesn't know if that is supposed to be W or West (and neither
do I). The old
But Serge IS testing. He is building and testing a script that is
conservative and gives feedback on what it isn't sure about. That info can
be used for future scripts, or manual edits.
He is only editing ways originally imported by tiger, based on the tiger
prefix, suffix, road type, and base
On Sat, May 12, 2012 at 2:20 AM, Dale Puch dale.p...@gmail.com wrote:
Nice work. See the list of way names I posted in the other thread for some
odd name or tag test cases.
Dale,
What I need at this point are people to look at the code, and give
concrete feedback directly on the functionality
On 11 May 2012 22:17, Dale Puch dale.p...@gmail.com wrote:
I understand the script checks for only one instance of the abbreviation.
My point was what is someone manually expanded ONE of the abbreviations,
leaving st something street? Is that checked for? The question also
applies to Dr
On Sat, May 12, 2012 at 12:41 PM, Serge Wroclawski emac...@gmail.com wrote:
On Sat, May 12, 2012 at 7:05 AM, Anthony o...@inbox.org wrote:
What percentage of roads, where the old script would have punted, are
now being expanded correctly?
The new script is up now.
I used Maryland as a test
On Sat, May 12, 2012 at 4:21 PM, andrzej zaborowski balr...@gmail.com wrote:
It checks suffixes starting from the
end, so if you have St something St E or St something St East,
it'll only check E or East and then St and then stop because
something is not a known suffix.
So Calle Ave Maria
On Sat, May 12, 2012 at 4:47 PM, Anthony o...@inbox.org wrote:
On Sat, May 12, 2012 at 4:21 PM, andrzej zaborowski balr...@gmail.com wrote:
It checks suffixes starting from the
end, so if you have St something St E or St something St East,
it'll only check E or East and then St and then stop
On 5/12/2012 12:41 PM, Serge Wroclawski wrote:
What error rate is acceptable?
As low as possible, but I've been generally able to handle the edge
cases I've seen, either by doing the right thing, or by punting and
doing nothing at all.
It's worth noting that any errors are already there as
The process seems obvious to me: check that the name is still what it
originally was (from the tiger:name_base etc. tags), and if so, use
those tags to expand abbreviations. (Ignore any with semicolons/colons
from joining.) If not, set it aside for semi-manual checking. The only
false
On Sat, May 12, 2012 at 5:27 PM, Nathan Edgars II nerou...@gmail.com wrote:
It's worth noting that any errors are already there as errors in the TIGER
tags. So, had the TIGER import been done properly in the first place, these
errors would be in the name tags as well.
This seems to be the
On 5/12/2012 5:54 PM, Anthony wrote:
If so, this is good, but it does mean that road names are going to get
out of sync, if, for instance, tiger:name_base was removed from some
of the ways and not removed from others. This will complicate later
fixes/enhancements.
This also happens long
On Sat, May 12, 2012 at 6:01 PM, Mike N nice...@att.net wrote:
On 5/12/2012 5:54 PM, Anthony wrote:
If so, this is good, but it does mean that road names are going to get
out of sync, if, for instance, tiger:name_base was removed from some
of the ways and not removed from others. This will
13 matches
Mail list logo
