Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is the message you get:
Error during map rendering: TypeError: features[i] is null
When an OpenLayersWKT typed field contains non-collection typed geometry, like:
POINT(0 0)
rather than
GEOMETRYCOLLECTION(POINT(0 0))
Dunno if this is an OpenLayers or drupal module limitation.
Comment | File | Size | Author |
---|---|---|---|
#17 | Trail layer in red | 235.38 KB | freelock |
#17 | Red layer should appear here | 232.49 KB | freelock |
Comments
Comment #1
tmcw CreditAttribution: tmcw commentedThe OpenLayers CCK field is not designed to work with non-typed geometries, which is fine, because it never creates non-collection typed geometries. If another module is creating stuff that doesn't align with this, shouldn't that module be the one to edit it?
Comment #2
strk CreditAttribution: strk commentedI think the OL module should be more tolerant to such things. For instance, this originated by myself adding manual WKT to the map while the editing toolbar was not showing up in Chrome due to "Zoom To Layer" being activated and WKT being null.
POINT(0 0) is valid and common WKT. GEOMETRYCOLLECTION is not very common as it allows for mixed type of geometries which
would need different type of styling (fills for poligons, strokes for lines, icons for points...).
Anyway, in this case I guess the fix would be rejecting unsupported input in the WKT field. If you accept it, you can't choke afterwards.
Comment #3
zzolo CreditAttribution: zzolo commentedI am going to change the focus of this issue to manual input of WKT, as this is actually the problem, IMO.
Personally, I think the textarea should be hidden by default (much like in 1.x) as anyone who doesn't know what WKT is, should not be seeing it. Second, if we are going to allow people to edit it, then we need to put some help text below it to ensure that there is guidance and tell the user that only certain data will work.
Thoughts?
Comment #4
zzolo CreditAttribution: zzolo commentedThinking about this more, I think the WKT input should just not be there at all. We should not support manual input of WKT for many reasons, most specifically we are not going to do validation on WKT.
Please note that technically OL depends on JS, so we should remove this input via JS, and "allow" (with heavy help text against) manual input.
Comment #5
zzolo CreditAttribution: zzolo commentedtagged as beta blocker
Comment #6
strk CreditAttribution: strk commentedManual input surely helps debugging. Maybe make it a widget configuration to show it or not, and default collapse state if shown.
Comment #7
zzolo CreditAttribution: zzolo commentedYes, definitely, but that just means there could be some ability to have read only output, and it should only be given to administrators.
Comment #8
strk CreditAttribution: strk commenteddunno what you mean by read-only. if it's for debugging should also allow writing.
Also, make sure the field is there. Maybe invisible but available to other modules.
I belive the the OpenLayersGeocoder module for example uses it.
Comment #9
zzolo CreditAttribution: zzolo commentedI dont see why debugging would need to be written, but the access point still applies.
Yes, my point about the JS means that the DOM element can still be there to be manipulated, just not be accessed normally.
Comment #10
Sanjo CreditAttribution: Sanjo commentedI agree with #3. There should be an option to turn this WKT field on and off and as default it's disabled.
Comment #11
zzolo CreditAttribution: zzolo commentedPlease note that the WKT field input box is not hidden by default:
http://drupal.org/node/882190
I am going to remove the beta-blocker status, since the interface change of hiding it my default is a short-term solution to the core issue which is that we do not currently support manual input of WKT. I don't personally think we should, but there is still room for discussion and improvement on this issue.
Comment #12
freelockI'd like to add a comment: it seems like manual editing of the WKT is essential to edit data on an existing node. Or am I overlooking something? I don't see any way of making corrections to WKT data using the map UI -- if you want to adjust the position of a point or add new points or delete an extraneous line, editing the WKT is essential.
We're working on a project involving a lot of mapping, and the people we're supporting don't seem to have that much trouble editing WKT text. If there's an easier way to make these edits, I'd certainly appreciate a pointer...
Comment #13
tmcw CreditAttribution: tmcw commentedfreelock: you can click the edit button (the farthest-left) and click on features to move or delete (with 'd') them.
Comment #14
freelocktmcw: thanks for the pointer... but this isn't working, I can't seem to select (or even see) the lines/points to edit.
Oh, wait a minute, take that back... I can edit points. But I can't seem to edit any lines. Does that functionality exist?
Actually, what I'm seeing is that points appear on a "features" layer when I'm editing an existing node, but lines do not. It looks like the points are picking up colors from the "Default Selected Style", which does define a line color and stroke width of 4 -- but the lines to edit do not appear, and I cannot select or move them. What am I missing?
Comment #15
tmcw CreditAttribution: tmcw commentedOkay, so basically your situation is that you can't see lines that are supposed to be shown by the WKT field? How was the data input?
Comment #16
freelockThe lines were originally drawn on the map. As you draw the lines, they show up using the default orange style.
After saving, the lines show up just fine in a preset and style I've defined.
When I go to edit the lines, they show up in the layer defined in my preset, but if I hide that layer, the lines disappear -- they don't appear on the "features" layer (which looks like the layer available to edit?). Points do.
Comment #17
freelockHi,
Thanks for your help. Attaching a couple screenshots to show what I'm trying to do...
First one shows a line that's described in the WKT field on this node being edited, and the preset shows it in red in the "Trail" overlay. So when I disable that overlay (2nd screenshot) I expect to see the line in some form I can select and edit. Nothing...
A different content type and openlayer view defines the points, and when I edit those content items, I can indeed see, move, and delete the points using exactly this preset (but by disabling the "Map Points" overlay).
Comment #18
freelockOk, sorry for the noise, figured it out... My custom style set the line color and type based on other CCK fields, which obviously aren't available when editing. Fixed it by setting the preset's "Default Style" back to a style that did not rely on a variable.
I do see one other issue here though, related to editing lines: it looks pretty easy to add new points in the line, but is there a way of removing extra points? When I tried the "d" key it deleted the entire line...
I still would like to have the option of inputing/editing WKT text, but I think it's fine to hide the field by default. It has proven useful for importing data from another system -- we've got a legacy system outputting lat/long pairs, and it's easy enough to munge that into WKT and paste or bulk import. I am planning to update this patch for OL2 support: #865232: Support for OpenLayers WKT -- Solution attached
Comment #19
tmcw CreditAttribution: tmcw commentedOkay, closing.
To delete individual points, I think you can select a point on a line. Otherwise, not sure - check openlayers.org.