[OSM-talk] TIGER in Santa Barbara County, CA

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Perry wrote:
> 
> How about this for a solution? All Tiger data within the BBOX of
> 34.35, -119.93, 34.52, -119.61 gets removed. Then we can merge
> everything along the edges? I think thats a fair choice.

I'm sure I must be missing something here, but why can't people just do
something like:

1. Load that area into josm
2. Type "property:source=tiger" in the search box and press return
3. Press delete

when tiger data goes over other (better) data?

You should also be able to search for something like
"-property:source=tiger" to get the non-tiger data.

Surely if it isn't this easy, then it could be, and we shouldn't spend
so much time worrying about the Tiger data going over other data.

Also, validator has a similar names and a crossing ways feature, both of
which are likely to help finding ways to delete from Tiger that already
exist in the map. Perhaps Validator could have a fix button for these
that was able to remove the tiger way and leave the old way intact.

I've not been working on anything like this, but I can't see how
delaying importing tiger data for areas that already have some mapping
helps anyone. It's just delaying the inevitable effort in sorting out
the problems, and in the mean time, people in the area might map some
more stuff that tiger already has, where they could be consciously
fixing problems in the Tiger data itself. Personally, I would prioritise
uploading Tiger data to areas that have other data already, before the
people in those areas do any more unnecessary work.

Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYU6Tz+aYVHdncI0RAtkxAJ9Ow1RuwFRd9XyM5QguZKzAmIxSZQCg15vO
dZsbDGgyVdTFAVlSqYzOCGQ=
=hmiv
-----END PGP SIGNATURE-----