-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for OSM JSON format #44
Conversation
b29a78a
to
ac1f60f
Compare
33974c8
to
37b52e8
Compare
8baac05
to
8b0219b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really keen on the structure of this in terms of how it is broken down into commits, especially how we essentially have two fixup commits for the JSON parser.
I'd suggest having one commit to fix the XML tests, then one to introduce the JSON parser in it's final form and then one to add JSON tests (though that could equally be included with the JSON parser addition).
Even better would be to refactor the XML parser along the same lines as the JSON parser after fixing the XML tests and before adding the JSON parser but that's obviously not essential so I wouldn't insist on that.
leaflet-osm.js
Outdated
relations = L.OSM.getRelations(xml, nodes, ways); | ||
buildFeatures: function (data) { | ||
|
||
const parser = (data.version) ? L.OSM.JSONParser : L.OSM.XMLParser; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably this is relying on data
either being a JSON object (that has a version
member) or an XML object (that doesn't) but that seems quite fragile... Could we use instanceof
instead to check the type of the data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, data.version is quite fragile, and I also don't really like this approach. I need to check for some alternatives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't have much luck with instanceof, (data instanceof Document)
fails in the test environment with ReferenceError: Document is not defined.
typeof data === 'object'
didn't work either, because both JSON and XML would match the condition.
(data.constructor.name === "Document")
would be another option, also not very nice.
https://developer.mozilla.org/en-US/docs/Web/API/Document/documentElement might be better than checking data.version?
const parser = (data.documentElement ? L.OSM.XMLParser : L.OSM.JSONParser);
This last option at least passes the unit tests.
jquery isXMLDoc has a more complex logic, which at one point also checks documentElement
: https://github.com/jquery/jquery/blob/098591e6fd3222e64b59af92c8849f5d8963d43c/src/core.js#L313-L320
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using data instanceof XMLDocument
seems to work for me? Both with my suggested test parsing technique and debugging the current code with the data layer on. JSON is tricky because it just returns an Object
rather than anything JSON specific...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm giving data instanceof XMLDocument
a try on GH actions, maybe my local environment has some issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah it works with DOMParser
in the browser but not with jsdom
which returns something that seems to inherit from Document
but which is a plain object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we add jsdom-global
to the modules then this seems to work:
> require('jsdom-global')()
[Function: cleanup]
> parser = new window.DOMParser();
DOMParser {}
> data = parser.parseFromString("<osm><node/><node/></osm>", "text/xml");
Document { location: [Getter/Setter] }
> data instanceof Document
true
Unlike a true browser it returns Document
not XMLDocument
but instanceof Document
works for both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Funny, I was just reading the exact same proposal here: https://stackoverflow.com/questions/42649700/using-domparser-in-javascript-testing-with-mocha-and-jsdom
I'll give it a try...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a6dac1a
to
9c5415e
Compare
Thank you for reviewing the code. I think it's easier to create a new PR to fix the existing XML tests, then continue with the JSON part... |
9c5415e
to
bdb75a1
Compare
9317a8f
to
c0a934c
Compare
c0a934c
to
6777e17
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good now, thanks.
Following the discussion in openstreetmap/openstreetmap-website#5474 (comment), I'm adding OSM JSON support to this package.
Summary of changes:
Unit test changes:
<node/>
by<node></node>
(see commit messages for details)layers(osm).length.should.eq(...);
was also fixedThe bug fix was required to keep xml and json unit tests in sync.
For code review I recommend split view + hide spaces in GitHub.