[JS]Firefox laad groot .gml (.xml) bestand niet

[PeaceNlove]

Ik probeer een .gml bestand in te lezen met JS, .gml is een speciale variant van XML en is ook opgesteld volgens de xml-standaard. Het bestand is +/- 1MB groot.
In IE 7 werkt het allemaal prima en levert een .getElementsByTageName keurig een getal >0 op, maar Firefox geeft telkens 0 terug en volgens mij laad het hele ding niet. Dit terwijl ik hezelfde stuk code ook gebruikt heb om een ander klein xmlbestand in te lezen, wat beiden wel goed doen.
Ik heb al op internet gezocht naar een oplossing hiervoor, en iets geprobeerd met de Readystate==4, maar dit hielp niet bepaald.
Ik heb alleen serverside Apache en Mapserver, maar geen PHP, ASP oid, dus ik moet helaas wel deze xml in zijn geheel bij de client laden.

Wat zou hier een oplossing kunnen zijn?

JS

JavaScript:

function parseXML()
{
try //Internet Explorer
  {
  xmlDoc=new ActiveXObject("Microsoft.XMLDOM");
  }
catch(e)
  {
  try //Firefox, Mozilla, Opera, etc.
    {
    xmlDoc=document.implementation.createDocument("","",null);
    }
  catch(e)
    {
    alert(e.message);
    return;
    }
  }
xmlDoc.async=false;
xmlDoc.load("content/Export_straat_Dissolve.gml");
var gml = xmlDoc.getElementsByTagName("gml:FeatureCollection");
alert(gml.length);

alternatief met readyState, vervangt de laatste regel van de vorige en werkt wel in IE, maar niet in FF

JavaScript:

if (xmlDoc.readyState==4){alert(gml.length);}.

gml

XML:

<?xml version="1.0" encoding="UTF-8" ?> 
- <gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fme="http://www.safe.com/gml/fme" xsi:schemaLocation="http://www.safe.com/gml/fme Export_straat_Dissolve.xsd">
- <gml:boundedBy>
- <gml:Envelope srsName="EPSG:28992" srsDimension="2">
  <gml:lowerCorner>68900 439861.846000001</gml:lowerCorner> 
  <gml:upperCorner>80865.5119999982 451370</gml:upperCorner> 
  </gml:Envelope>
  </gml:boundedBy>
+ <gml:featureMember>
- <fme:Export_straat_Dissolve gml:id="idf2a6db71-8b2f-4428-80de-905497cdf1bd">
  <fme:FID>0</fme:FID> 
  <fme:STT_NAAM>'S-GRAVENZANDE</fme:STT_NAAM> 
  <fme:WPSNAAMNEN>'S-GRAVENZANDE</fme:WPSNAAMNEN> 
  <fme:minx>72064</fme:minx> 
  <fme:maxx>72239</fme:maxx> 
  <fme:miny>444139</fme:miny> 
  <fme:maxy>444266</fme:maxy> 
- <gml:multiCurveProperty>
- <gml:MultiCurve srsName="EPSG:28992" srsDimension="2">
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>72209 444180 72222 444164 72239 444139</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>72064 444265 72077 444266 72138 444229 72150 444225 72159 444227</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
  </gml:MultiCurve>
  </gml:multiCurveProperty>
  </fme:Export_straat_Dissolve>
  </gml:featureMember>
- <gml:featureMember>
- <fme:Export_straat_Dissolve gml:id="id5727e240-adff-424e-a93b-997d25c5e312">
  <fme:FID>1</fme:FID> 
  <fme:STT_NAAM>'s-Gravenzandseweg</fme:STT_NAAM> 
  <fme:WPSNAAMNEN>MONSTER</fme:WPSNAAMNEN> 
  <fme:minx>70726.476</fme:minx> 
  <fme:maxx>71228</fme:maxx> 
  <fme:miny>448552.004</fme:miny> 
  <fme:maxy>448823</fme:maxy> 
- <gml:multiCurveProperty>
- <gml:MultiCurve srsName="EPSG:28992" srsDimension="2">
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>70726.4759999998 448552.004000001 70809 448618 70887 448680 70907 448696</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>70907 448696 70916 448698 70938 448708 70962 448715 70971 448717 70987 448721 71021.2980000004 448725.870999999 71051.4780000001 448727.151999999</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>70907 448696 70914.868999999 448703.122000001 70931.7630000003 448714.759 70952.7179999985 448723.013999999 70969.2280000001 448728.094000001 70989.2309999987 448733.809 71020.9809999987 448740.476 71042.4640000016 448745.254000001 71049.1209999993 448748.057999998 71061.2809999995 448753.181000002 71054.7509999983 448749.640000001 71051.4780000001 448746.420000002 71048.6499999985 448742.145 71048.0980000012 448735.941 71049.1730000004 448730.640000001 71051.4780000001 448727.151999999</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>71076.6700000018 448747.951000001 71079.6970000006 448743.046999998 71080.5139999986 448737.940000001 71080.1059999987 448733.855 71078.193 448729.125999998 71075.9180000015 448725.377999999 71070.8640000001 448723.219999999 71064.1640000008 448722.098999999 71057.5399999991 448723.318999998 71051.4780000001 448727.151999999</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>71062.2309999987 448758.151000001 71048 448754 71028 448750 70998 448743 70971 448736 70949 448729 70935 448724 70925 448721</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
- <gml:curveMember>
- <gml:LineString>
  <gml:posList>71067.8839999996 448758.576000001 71081 448768 71084 448769 71090 448772 71094 448773 71157 448789 71198 448801 71212 448807 71216 448811 71228 448823</gml:posList> 
  </gml:LineString>
  </gml:curveMember>
  </gml:MultiCurve>
  </gml:multiCurveProperty>
  </fme:Export_straat_Dissolve>
  </gml:featureMember>
- <gml:featureMember>

[ Voor 1% gewijzigd door PeaceNlove op 02-06-2009 12:19 . Reden: readystate toegevoegd ]

[crisp]

Serveer je je .gml bestand wel met een XML mimetype?

[PeaceNlove]

crisp schreef op dinsdag 02 juni 2009 @ 12:34:
Serveer je je .gml bestand wel met een XML mimetype?

Goeie vraag, maar het enige wat ik van de server weet is het adres en mijn ftp-login.
Ik heb het bestand hernoemd naar een .xml , maar dat helpt ook niet echt. Maar twee andere xmldocumenten worden wel netjes geladen door zowel FF als IE7, dus op zich lijkt het me correct aan te nemen dat de server de xml netjes doorstuurd en dat IE en FF de xml netjes aannemen in het try-catch stuk van mijn code.

In IE merk je wel dat het eventjes kost om het bestand te laden, maar daarna geeft het netjes het resultaat van de getElementsByTagName.
FF gaat direct door lijkt het wel in het origineel, er is geen pauze te bespeuren waarin FF de xml inlaad. Dit heb ik geprobeerd te ondervangen met de readyState, maar dan krijg ik totaal geen alert.

edit:
het volgende stukje code werkt wel weer in IE, maar niet in FF, sterker nog, FF gaat compleet vast op dit stukje

JavaScript:

while (xmlDoc.readyState!=4){document.getElementById("p").innerHTML = "loading";}

overigens wil IE dan niet het woordje loading weergeven in "p", maar soit

edit: volgloeiende , nu doet exact hetzelfde stuk code als het allereerste het wel. Probleem solved codetechnisch, maar waarom wil FF het dan de eerste keer niet doen?

[ Voor 20% gewijzigd door PeaceNlove op 02-06-2009 13:12 . Reden: typo ]

[djluc]

Test eerst eens met een klein bestandje dan weten we tenminste of het aan je code of aan het formaat ligt?

[PeaceNlove]

djluc schreef op dinsdag 02 juni 2009 @ 13:10:
Test eerst eens met een klein bestandje dan weten we tenminste of het aan je code of aan het formaat ligt?

Het werkt nu dus wel, zie mijn vorige post edit #2, maar onverklaarbaar voor mij is waarom FF eerst geen 0 terug gaf en nu >0

wat ik wel weet is dat FF bij een F5 alleen de html ververst en niet de xml's die er bij horen, maar ik heb continue ctrl-F5 gedaan om alles te verversen.

[supergert]

Ondersteund (jouw versie van) Firefox wel xmlDoc.readyState?
Dat zou verklaren waarom de loop "vastloopt", die is dan altijd != 4

Wat meer uitleg over XML laden in IE en FF (voor FF zie pagina 91 en verder)

[Bosmonster]

Dat die while vastloopt vind ik niet zo gek. Bij een groter bestand waarbij het een paar seconden duurt zit ie dan direct vast in een voor de browser oneindige loop.

Heb je al eens geprobeerd de xml op te halen met de ouderwetse XHR? Eventueel met behulp van een bestaande library?

[ Voor 26% gewijzigd door Bosmonster op 02-06-2009 13:39 ]