Re: [Talk-us] Address Lookup
I don't agree that there is no value in address range interpolation like TIGER uses. As anyone who has edited TIGER data knows, it is not very accurate. So cleaning that up (address aspects as well as geometry and attributes) is a valuable thing that we can do in OSM. Getting a viable geocoding function using address ranges is much more achievable in terms of the effort needed than doing individual properties. And the two approaches complement each other anyway - you can always search for a specific property address and fall back to an address range if you don't find it. Cheers, Peter. On May 21, 2010, at 4:24 AM, Apollinaris Schoell ascho...@gmail.com wrote: there is not much value to add address interpolation in US. this can be done easier and more consistent by using a plain tiger DB. only if detailed addresses are added to osm there is additional value. and yes this is a lot of work much more than streets. some counties offer detailed data and it can be imported easily. in other places it has to be done by survey. but wasn't that the idea of osm? competing with google in processing public data has no chance anyway. why not concentrate on the strengths of crowd sourcing. On 21 May 2010, at 6:45 , Val Kartchner wrote: The goal of Open Street Map is to eventually do everything that commercial map products do. This would include address lookup. I've looked around and the way of associating addresses with streets doesn't seem to work very well. The simplest way (requiring the fewest nodes) still requires a lot of work. For instance, for an example I've picked a street around my area: West 2550 North. This is just the ways needed for the streets themselves. (I didn't include the names on the cross streets because they don't matter for this example.) AB C D E || | | | || | | | +--+-+--+---+---+---+---+-- || | | | | || | | | | FG H From what I understand, next to each place where another street intersects this street I will have to create another node (on each side of the street) tagged with addr:street and addr:housenumber. I will need to connect the nodes on each side of the street with a relation. The relation I will need to tag with addr:interpolation and even/odd, as appropriate. This makes the simple street above now look like this: AB C D E || | | | || | | | **--*---*---*---*---*-* +--+-+--+---+---+---+---+-- **--*---*---*---*---*-* || | | | | || | | | | FG H This is a LOT of data to manually add. Is there a simpler way? No, I don't have a better idea. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Lookup
This is a LOT of data to manually add. Is there a simpler way? Yes, address information is laborious to collect and enter. There is a JOSM plugin to simplify the repetitive data entry aspect as much as possible, but it still takes quite a bit of effort. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Lookup
But, you cannot point to point dispatch using an interpolated address; so that's why a database without address points is not that much more valuable than the TIGER db for that purpose. TIGER is not that accurate, but it is precise for an interpolated range set. Without point to point, you are only getting a driver a topologically correct route that gets them in the general area. TIGER's precision (especially TIGER 2009) is enough for this. There is plenty of value above TIGER in other applications where accuracy matters more than precision, just not in the point to point dispatch application; and that is going to be the most valuable application. The work is not in the ground surveying; that really is relatively quick work if street addressing and point addressing are done at the same time. The work is in building the address to street associations. Unfortunately, I don't see how that can get any easier than how Val has diagrammed. That particular aspect becomes even more burdensome when done separately from the street addressing too (as you have to then search for the right street segment for each address). Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 -Original Message- Date: Fri, 21 May 2010 04:52:26 -0600 From: Peter Batty peter.ba...@gmail.com Subject: Re: [Talk-us] Address Lookup To: Apollinaris Schoell ascho...@gmail.com Cc: val...@gmail.com val...@gmail.com, OSM Talk US talk-us@openstreetmap.org Message-ID: 04041b59-cecc-4b4f-90ea-1c9ba680d...@gmail.com Content-Type: text/plain; charset=us-ascii I don't agree that there is no value in address range interpolation like TIGER uses. As anyone who has edited TIGER data knows, it is not very accurate. So cleaning that up (address aspects as well as geometry and attributes) is a valuable thing that we can do in OSM. Getting a viable geocoding function using address ranges is much more achievable in terms of the effort needed than doing individual properties. And the two approaches complement each other anyway - you can always search for a specific property address and fall back to an address range if you don't find it. Cheers, Peter. On May 21, 2010, at 4:24 AM, Apollinaris Schoell ascho...@gmail.com wrote: there is not much value to add address interpolation in US. this can be done easier and more consistent by using a plain tiger DB. only if detailed addresses are added to osm there is additional value. and yes this is a lot of work much more than streets. some counties offer detailed data and it can be imported easily. in other places it has to be done by survey. but wasn't that the idea of osm? competing with google in processing public data has no chance anyway. why not concentrate on the strengths of crowd sourcing. On 21 May 2010, at 6:45 , Val Kartchner wrote: The goal of Open Street Map is to eventually do everything that commercial map products do. This would include address lookup. I've looked around and the way of associating addresses with streets doesn't seem to work very well. The simplest way (requiring the fewest nodes) still requires a lot of work. For instance, for an example I've picked a street around my area: West 2550 North. This is just the ways needed for the streets themselves. (I didn't include the names on the cross streets because they don't matter for this example.) AB C D E || | | | || | | | +--+-+--+---+---+---+---+-- || | | | | || | | | | FG H From what I understand, next to each place where another street intersects this street I will have to create another node (on each side of the street) tagged with addr:street and addr:housenumber. I will need to connect the nodes on each side of the street with a relation. The relation I will need to tag with addr:interpolation and even/odd, as appropriate. This makes the simple street above now look like this: AB C D E || | | | || | | | **--*---*---*---*---*-* +--+-+--+---+---+---+---+-- **--*---*---*---*---*-* || | | | | || | | | | FG H This is a LOT of data to manually add. Is there a simpler way? No, I don't have a better idea. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- ___ Talk-us mailing list Talk-us@openstreetmap.org
Re: [Talk-us] Cloudmade california.osm: dups or osmosis bug?
Thanks for the patch - I'm also running into random dupes on CloudMade extracts for my state. Not sure if it's related, but I noticed that many of the CloudMade extracts can't be processed using osmosis (even though they're generated with osmosis), except for the operations that don't try to validate the order of elements. It seems they often contain consecutive elements with the same id, but possibly different version. I have a little patch (attached) to add a new filter (--ff) that flattens the file. It does the same operation on sorted entity streams as --simplify-change does on change streams, unfortunately --simplify is taken by a different operation now. I decided it was faster to modify osmosis than to download the planet and make my own un-broken extracts. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Lookup
On Fri, May 21, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: From what I understand, next to each place where another street intersects this street I will have to create another node (on each side of the street) tagged with addr:street and addr:housenumber. I will need to connect the nodes on each side of the street with a relation. The relation I will need to tag with addr:interpolation and even/odd, as appropriate. Whoa, that sounds like it might be an overstatement, or at least an exaggeration. You don't necessarily have to have an address node *every* block, but every few blocks (even one per mile) is probably going to be close enough for most uses. (At least as precise as Google's typical lookups, anyway...) You can probably just do addr:housenumber on each of those nodes. Then you connect all those nodes up with a way on each side of the street, which has the addr:interpolation tagging. (That way can have nodes along it that don't have addr:housenumber if necessary to follow the bends of the street or line of houses.) Also, those ways will probably have addr:street tags. Optionally, but perhaps ideally, those ways will be linked to the street itself using an associatedStreet relation. If the relation exists, then addr:street tags on the interpolation-ways can probably be omitted, as they can be inferred from the addr:street or name tag of the street itself. Now that doesn't sound like a terribly large amount of work to me. Of course, this is style is best for rows of houses and other small buildings that aren't already individually mapped. Large, important features should probably have their own, complete address information tagged directly. -- David Smith a.k.a. Vid the Kid a.k.a. Bír'd'in Does this font make me look fat? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Cloudmade california.osm: dups or osmosis bug?
Hi Mike,
good catch, I forgot to add the ...Factory.java file. Hopefully I
haven't forgotten any more files.
Cheers
On 22 May 2010 04:08, Mike N. nice...@att.net wrote:
Hi andrzej,
I tried to apply the patch, but I get an undefined symbol when trying to
build 'FlattenFilterFactory'. Am I missing part of the patch or is there
another setting to create the Factory?
Thanks,
Mike Nice
--
From: andrzej zaborowski balr...@gmail.com
Sent: Friday, May 21, 2010 2:40 PM
To: David Carmean d...@halibut.com
Cc: osmosis-...@openstreetmap.org; OSM US Talk
talk-us@openstreetmap.org
Subject: Re: [Talk-us] Cloudmade california.osm: dups or osmosis bug?
Hi,
On 21 May 2010 01:54, David Carmean d...@halibut.com wrote:
Is it the dataset or osmosis that is giving me a single 2-node duplicate
for each postGIS table created by osmosis?
Not sure if it's related, but I noticed that many of the CloudMade
extracts can't be processed using osmosis (even though they're
generated with osmosis), except for the operations that don't try to
validate the order of elements. It seems they often contain
consecutive elements with the same id, but possibly different version.
I have a little patch (attached) to add a new filter (--ff) that
flattens the file. It does the same operation on sorted entity
streams as --simplify-change does on change streams, unfortunately
--simplify is taken by a different operation now. I decided it was
faster to modify osmosis than to download the planet and make my own
un-broken extracts.
Cheers
(I'm not subscribed to osmosis-dev)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Index: src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilter.java
===
--- src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilter.java (revision 0)
+++ src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilter.java (revision 0)
@@ -0,0 +1,91 @@
+/* This software is released into the Public Domain.
+ * See copying.txt for details. */
+package org.openstreetmap.osmosis.core.filter.v0_6;
+
+import org.openstreetmap.osmosis.core.container.v0_6.BoundContainer;
+import org.openstreetmap.osmosis.core.container.v0_6.EntityContainer;
+import org.openstreetmap.osmosis.core.container.v0_6.EntityProcessor;
+import org.openstreetmap.osmosis.core.domain.v0_6.Entity;
+import org.openstreetmap.osmosis.core.task.v0_6.Sink;
+import org.openstreetmap.osmosis.core.task.v0_6.SinkSource;
+
+
+/**
+ * Flatten / simplify a sorted entity stream.
+ * (similar to --simplify-change)
+ */
+public class FlattenFilter implements SinkSource {
+ private Sink sink;
+ private EntityContainer previous_container;
+
+ /**
+ * Creates a new instance.
+ */
+ public FlattenFilter() {
+ }
+
+ /**
+ * Process a node, way or relation.
+ *
+ * @param current_container
+ *The entity container to be processed.
+ */
+ public void process(EntityContainer current_container) {
+ if (previous_container == null) {
+ previous_container = current_container;
+ return;
+ }
+
+ Entity current = current_container.getEntity();
+ Entity previous = previous_container.getEntity();
+
+ if (current.getId() != previous.getId() ||
+current.getClass() != previous.getClass()) {
+ sink.process(previous_container);
+ previous_container = current_container;
+ return;
+ }
+
+ if (current.getVersion() previous.getVersion())
+ previous_container = current_container;
+ }
+
+ /**
+ * Process the bound.
+ *
+ * @param boundContainer
+ *The bound to be processed.
+ */
+ public void process(BoundContainer boundContainer) {
+ /* By default, pass it on unchanged */
+ sink.process(boundContainer);
+ }
+
+ /**
+ * {...@inheritdoc}
+ */
+ public void complete() {
+ /*
+ * If we've stored entities temporarily, we now need to
+ * forward the stored ones to the output.
+ */
+ if (previous_container != null)
+ sink.process(previous_container);
+
+ sink.complete();
+ }
+
+ /**
+ * {...@inheritdoc}
+ */
+ public void release() {
+ sink.release();
+ }
+
+ /**
+ * {...@inheritdoc}
+ */
+ public void setSink(Sink sink) {
+ this.sink = sink;
+ }
+}
Index: src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilterFactory.java
===
--- src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilterFactory.java (revision 0)
+++ src/org/openstreetmap/osmosis/core/filter/v0_6/FlattenFilterFactory.java (revision 0)
@@ -0,0 +1,26 @@
+/* This software is released into the Public Domain.
+ * See copying.txt for details. */
+package org.openstreetmap.osmosis.core.filter.v0_6;
+
+import org.openstreetmap.osmosis.core.pipeline.common.TaskConfiguration;
+import org.openstreetmap.osmosis.core.pipeline.common.TaskManager;
+import
