On Nov 20, 2007 11:30 AM, Brent Easton <<a href="mailto:b.easton@exemail.com.au">b.easton@exemail.com.au</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Thanks Brett, That makes sense. Ultimately we will want to clean up the DB. In the meantime, looks like 2 approaches:- 1. Stop OSMXAPI from emitting non-existent nodes in ways. Since we know that it represents a DB inconsistency, I think it is reasonable that xapi suppress them rather than emitting them. While we're at it, I think xapi should also suppress ways that contain only one node. Is the source for osmxapi in the SVN somewhere?

<br></blockquote><div><br>IMHO Osmxapi shouldn't do this.  It should mimic as exactly as possible what the main API does.  If the main api stops emitting non-existent nodes then osmxapi will also.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

2. Have Osmarender filter out the extraneous nodes.  Dodi, can we do this in Osmarender.xsl? </blockquote><div> Osmarender should do this.  It should be tolerant of missing nodes and make an appropriate decision when it encounters this case.  It should certainly alway produce valid SVG so as to not break Batik or anything else.

<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Regards,<br>Brent.<br><br><br><br>*********** REPLY SEPARATOR  ***********<br>

<div><div></div><div class="Wj3C7c"><br>On 20/11/2007 at 9:55 PM Brett Henderson  wrote:<br><br>>That problem has been created by potlatch.  It's a known issue that<br>>RichardF is working on but I think he's been struggling to get to the

<br>>bottom of it (haven't heard an update for a while).  If you look at the<br>>times you'll see that the node was deleted 11 seconds prior to the way.<br>>It appears to be triggered by slow network links where potlatch updates

<br>>take some time to reach the main db.  I don't know if potlatch is doing<br>>referential integrity checks on the client or server ...<br>><br>>There are plenty more errors like it in the main db.  This link is a

<br>>referential integrity report I ran a couple of weeks ago.  It's 43K<br>>gzipped and contains over 27545 records.<br>><a href="http://www.bretth.com/osm/integrity-report-20071106.csv.gz" target="_blank">http://www.bretth.com/osm/integrity-report-20071106.csv.gz

</a><br>><br>>Brent Easton wrote:<br>>> Hi 80n,<br>>><br>>> Comments below,<br>>><br>>> Regards,<br>>> Brent.<br>>><br>>> *********** REPLY SEPARATOR  ***********<br>>>

<br>>> On 20/11/2007 at 8:21 AM 80n  wrote:<br>>><br>>><br>>>> On Nov 20, 2007 1:28 AM, Brent Easton <<a href="mailto:b.easton@exemail.com.au">b.easton@exemail.com.au</a>> wrote:<br>>>>

<br>>>><br>>>>> I am seeing inconsistent data being returned by OSMXAPI when doing<br>>>>> lowzooms. Ways are referencing nodes that are not included in download.<br>>>>><br>>>> When

<br>>>><br>>>>> you go an view the actual data, that node no longer exists. This seems<br>>to<br>>>>> indicate that it is some sort of timing issue. The end result is that<br>>>>>

<br>>>> Batik<br>>>><br>>>>> crashes trying to render the lowzoom tiles.<br>>>>><br>>>>><br>>>> Osmxapi *should* be consistent providing its sources are consistent.  I

<br>>>> know<br>>>> planet.osm is not guaranteed to be consistent but I think that the<br>>planet<br>>>> diffs are supposed to be.  Brett can you confirm that?<br>>>><br>>>> I ran a full consistency check on osmxapi just a couple of days ago.  At

<br>>>> that point it seemed ok.  Brent, can you give me some example way Ids so<br>>>> that I can track down where the problem came from please?<br>>>><br>>><br>>><br>>> Way 5403535 is good one to start, while trying to run

<br>>><br>>> perl tilesgen.pl xy 235 150 8<br>>><br>>> Generates<br>>><br>>>   <way id='5403535' timestamp='2007-09-02T10:39:00+01:00'><br>>>     <nd ref='35298243'/>

<br>>>     <nd ref='38879056'/><br>>>     <nd ref='38879058'/><br>>>     <nd ref='38879060'/><br>>>     <nd ref='38879063'/><br>>>     <nd ref='38879066'/>

<br>>>     <nd ref='38879069'/><br>>>     <nd ref='38879072'/><br>>>     <nd ref='38879076'/><br>>>     <nd ref='38879079'/><br>>>     <nd ref='38879084'/>

<br>>>     <nd ref='38879088'/><br>>>     <nd ref='38879091'/><br>>>     <nd ref='38879093'/><br>>>     <nd ref='38879096'/><br>>>     <nd ref='38879098'/>

<br>>>     <nd ref='38879100'/><br>>>     <nd ref='38879103'/><br>>>     <nd ref='38879107'/><br>>>     <nd ref='38879111'/><br>>>     <nd ref='38879115'/>

<br>>>     <nd ref='38879119'/><br>>>     <nd ref='38879123'/><br>>>     <nd ref='38879127'/><br>>>     <nd ref='38879132'/><br>>>     <nd ref='38879137'/>

<br>>>     <nd ref='38879139'/><br>>>     <tag k='highway' v='secondary'/><br>>>     <tag k='ref' v='15'/><br>>>   </way><br>>>

<br>>> in the data-pid-4.osm file, but all except the first node do not appear<br>>in the file.<br>>><br>>><br>>><br>>><br>>>>> Is this a known issue? I am presuming the planet.osm

dump is >>>> >>> inconsistent. >>> >>>> Where should we look at solving this problem :- >>>> >>>> 1. Planet.osm dump is inconsistent, fix that?

<br>>>>><br>>>>><br>>>> Osmxapi uses planet diff files so fixing planet.osm won't help much.<br>>>><br>>>><br>>>><br>>>>> 2. Fix OSMXAPI to not emit nodes in ways that have not been included in

<br>>>>> the download file?<br>>>>><br>>>> It's intentional behaviour that if the ways references a non-existant<br>>node<br>>>> then the node will not be in the output, but the way will still contain

<br>>the<br>>>> offending <nd> tag.  It didn't seem to make sense to remove it as the<br>>>> client<br>>>> cannot then detect that the way is incomplete.  The client should choose<br>

>>> how<br>>>> to process such error situations, although this fact should be<br>>mentioned in<br>>>> the docs.<br>>>><br>>>><br>>>><br>>>>> 3. Have Osmarender ignore undefined nodes? Is this possible with XSLT?

<br>>>>><br>>>>><br>>>> It used to be able to deal with missing nodes, but maybe this broke<br>>during<br>>>> the 0.4 to 0.5 migration.<br>>>><br>>><br>>> The problem is not so much Osmarender as Batik. Inkscape handle errors

<br>>by ignoring them, Batik fails.<br>>> I will see if I can see anything in old versions of the source and also<br>>run it past Dodi.<br>>><br>>> Thanks,<br>>> Brent.<br>>><br>>>

<br>>> ____________________________________________________________<br>>> Brent Easton<br>>> Analyst/Programmer<br>>> University of Western Sydney<br>>> Email: <a href="mailto:b.easton@uws.edu.au">

b.easton@uws.edu.au</a><br>>><br>>><br>><br>><br></div></div>>--<br>>No virus found in this incoming message.<br>>Checked by AVG Free Edition.<br>>Version: 7.5.503 / Virus Database: 269.16.0/1139 - Release Date: 19/11/2007 12:35 PM

<br><div><div></div><div class="Wj3C7c"><br><br>____________________________________________________________<br>Brent Easton<br>Analyst/Programmer<br>University of Western Sydney<br>Email: <a href="mailto:b.easton@uws.edu.au">

b.easton@uws.edu.au</a><br><br></div></div></blockquote></div><br>