[OSM-dev] Empty Keys, possible planet.c problem?

Jon Burgess jburgess777 at googlemail.com
Sun Sep 30 12:36:15 BST 2007


On Sun, 2007-09-30 at 12:59 +0200, Frederik Ramm wrote:
> Hi,
> 
>    the excerpts below are from the latest (070928) planet file (I
> grepped for the string 'tag k=""').
> 
> If you verify them against the API you will find that some of these
> empty keys are genuine, and thus may point to Potlatch and JOSM
> problems (I don't suppose they should allow uploadig empty keys). 
> 
> But most of the empty keys are "phantom" empty keys. For example the
> very first one in the list, node 649737, does not have any tags when
> retrieved from the API, and according to history never had any!
> 
> I assume that this *might* be a planet.c problem since it is my
> understanding that this is the first planet file to be generated that
> way, but I haven't looked at the planet.c source (and any systemic
> problem would probably show up much more often than the handful of
> instances I have found...)
> 
> Bye
> Frederik
> 
> 
>   <node id="649737" lat="-36.1725469" lon="175.3964968" timestamp="2006-03-24T18:47:06+00:00">
>     <tag k="" v="" />
>   </node>
>   <node id="36126209" lat="46.5204193" lon="15.5946868" timestamp="2007-08-25T20:44:36+01:00">
>     <tag k="created_by" v="JOSM" />
>     <tag k="name" v="Koča Luka" />
>     <tag k="" v="" />
>   </node>
>   <node id="46458531" lat="66.3878479" lon="12.8068608" timestamp="2007-09-08T10:03:49+01:00">
>     <tag k="" v="undefined" />
>   </node>
>   <segment id="151997" from="195852" to="195420" timestamp="2006-02-22T08:42:34+00:00">
>     <tag k="class" v="residential" />
>     <tag k="" v="" />
>   </segment>
>   <segment id="261842" from="304180" to="304181" timestamp="2005-12-10T14:06:14+00:00">
>     <tag k="" v="" />
>   </segment>
>   <way id="5174186" timestamp="2007-08-25T03:28:39+01:00">
>     <seg id="31863910" />
>     <tag k="aeroway" v="taxiway" />
>     <tag k="created_by" v="Potlatch alpha" />
>     <tag k="" v="" />
>   </way>
>   <way id="5192218" timestamp="2007-08-26T10:03:15+01:00">
>     <seg id="32142058" />
>     <seg id="32142059" />
>     <seg id="32142060" />
>     <seg id="32142061" />
>     <seg id="32142062" />
>     <tag k="" v="delete this" />
>     <tag k="created_by" v="Potlatch alpha" />
>     <tag k="natural" v="water" />
>   </way>
>   <way id="5364320" timestamp="2007-09-02T01:26:57+01:00">
>     <seg id="34429860" />
>     <seg id="34429861" />
>     <seg id="34429862" />
>     <seg id="34429863" />
>     <seg id="34429864" />
>     <seg id="34429865" />
>     <seg id="34429866" />
>     <seg id="34429867" />
>     <seg id="34429868" />
>     <seg id="34429869" />
>     <seg id="34429870" />
>     <seg id="34429871" />
>     <seg id="34429872" />
>     <tag k="" v="" />
>     <tag k="name" v="A4146" />
>     <tag k="created_by" v="Potlatch alpha" />
>     <tag k="highway" v="secondary" />
>     <tag k="oneway" v="-1" />
>   </way>
>   <way id="6116772" timestamp="2007-09-13T14:02:32+01:00">
>     <seg id="45557929" />
>     <seg id="45557933" />
>     <tag k="" v="Schlöglgasse" />
>     <tag k="created_by" v="JOSM" />
>     <tag k="highway" v="residential" />
>   </way>
> 

Thanks for point out these odd entries. Looking at the raw DB tables
shows these are bad entries in the database:


mysql> select id,tags from current_nodes where id in (649737,36126209,46458531);
+----------+-----------------------------------+
| id       | tags                              |
+----------+-----------------------------------+
|   649737 | =                                 |
| 36126209 | created_by=JOSM;name=Koča Luka;= |
| 46458531 | =undefined                        |
+----------+-----------------------------------+
3 rows in set (0.03 sec)

mysql> select id,tags from current_segments where id in (151997,261842);
+--------+----------------------+
| id     | tags                 |
+--------+----------------------+
| 151997 | class=residential;=; |
| 261842 | =;                   |
+--------+----------------------+

mysql> select * from current_way_tags where id in (5174186,5192218,5364320,6116772);
+---------+------------+----------------+
| id      | k          | v              |
+---------+------------+----------------+
| 5174186 | aeroway    | taxiway        |
| 5174186 | created_by | Potlatch alpha |
| 5174186 |            |                |
| 5192218 |            | delete this    |
| 5192218 | created_by | Potlatch alpha |
| 5192218 | natural    | water          |
| 5364320 |            |                |
| 5364320 | name       | A4146          |
| 5364320 | created_by | Potlatch alpha |
| 5364320 | highway    | secondary      |
| 5364320 | oneway     | -1             |
| 6116772 |            | Schlöglgasse  |
| 6116772 | created_by | JOSM           |
| 6116772 | highway    | residential    |
+---------+------------+----------------+
14 rows in set (0.18 sec)

The planet.rb code and the API probably use the same piece of code to
convert the tags string into key/value pairs and both presumably exclude
empty keys.

I can either make the planet.c code follow the lead of the Ruby and
ignore these empty keys or we can clean up the DB, or we can just ignore
the problem. Personally I'd think the best approach would be to clean
the DB. Any other thoughts?

	Jon







More information about the dev mailing list