[Talk-us] addressing format

[Apollinaris Schoell]

SteveC wrote:
> 
> Thinking about this 'numbers on nodes' schema... let's say it's perfect and we all agree, then who's going to do the import work for it?
> 
> It requires matching up past and present geometries to find the correct nodes to update, and, er, that's the hard bit of coding with the Karlsruhe schema ways with the new geometries that Dave has explicitly bowed out from...
> 
>   

As you wrote earlier. At the end the Karlruhe scheme is the only good solution. read on

I have checked the current osm files form Dave and as hard as I try I can't think of a reason to import them. but many why it shouldn't be imported
- a new way is created at same location as the existing tiger way. Editing this clutter is difficult in Josm. Nearly impossible in Potlatch(ok not an Potlatch expert so there might be tricks with overlapping ways)
- editing in Josm will connect nodes when adding new connecters. which point will be used? no idea, maybe randomly an address way node and the next time a road way node. this will lead to non connected road network. Potlatch is similar in trying to connect new ways automatically to existing ways.
- validator will flag all nodes as duplicates and try to fix them and will end up with duplicate ways. Makes editing a pain.
- rendering addresses is not possible now and nearly impossible to implement in the future with this data. Rendering will need to understand this data create parallel ways with correct numbers left and right. If a renderer can do it why can't the conversion and import do it? Wasn't there a phyton script to convert it to Karlsruhe Scheme? if rendering isn't done what is the purpose of importing the data? 
- modified tiger roads will not overlap exactly the new import. rendering will be horrible. if we omit the highway tag this isn't a problem
- geocoding is another use, but why build it based on osm? importing tiger in a DB is much easier and update cane be done within hours. a merge of new tiger address data into osm will be a nightmare.
- navigation software. none of the existing solutions can understand it. Is anyone interested in US volunteering to add support? again if we have all the duplicated ways and nearly duplicates it will break most existing navi software. any import like that must not break a majority of existing tools.
- far too many useless tags, this can be easily changed. except tlid and address attributes none of the tags is needed. All is_in tags are useless. with state, county, city borders this can always be derived from the polygons. If a border changes the ways will automatically refer to new location.
- amount of data is huge. current tiger cleanup on nodes may need approx half a year. an import will probably need closer to a year. And then the next version of tiger is available. Whenever you start you will be disappointed by the data quality when finished. 
- conversion of this data to Karlsruhe scheme will be as much work as entering all of it manually or even worse because of the cleanup. And Karlsruhe scheme should be our end goal for the perfect map.
- osm file size is huge and doesn't allow efficient edits before upload. this will again kill the community because it has to be driven from a central group. and community can deal with the huge clutter.
- tiger contains a lot of dead data, as discussed earlier many roads have been abandoned, even if we consider it as potential address why import? a potential address range isn't on the ground and probably never will be or slightly changed. let's add addresses when they come into existence. 


bottom line, convert to Karlsruhe scheme AND use Roadmatcher (or similar tools) to filter areas where the new data diverges from the existing osm data or 
don't import and build a US geocoding server based on Tiger for all kinds of services where it useful. A simple osm exporter can convert to and merge into a planet file for osm based tools.

haven't used Roadmatcher but read talk-ca and I am sure Sam can explain how that works. an I know he reads talk-us. Let's see if he has given up on this thread already ;-)

Waiting for pro arguments …

--
Apollinaris

> Yours &c.
> 
> Steve
> 
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20091116/de1ddbc2/attachment.html>