Hi guys, I know you probably dont want to hear about 1.x issues, but this one is likking me and for the life of me I cant get my head around it.
First, I have a wkt field in my custom content type. I had the follwing code in the PHP default value field in the content type:

$lat='65.5';$lon='-120.5';
$point="POINT(".$lon." ".$lat.")";
return array(0 => array('openlayers_wkt' => $point));

So when the user creates a new node, the map has this point on it already as a default. Now normally our business process is that you enter the lat long when you have the data and you use the map to guess when you dont. For some reason, the wkt field no longer works for normal users, me, nor the root user (eliminates any permissions issues)
When I open the field under the map, and replace the default wityh my own correctly formatted WKT value of POINT(-123 61) it ignores the new value and saves with the default. So next I edited the contentype, and the location field, and removed all code and values in defaults.
Saved the field, saved the content type, blew away the cache and when I create a new node, the default still remains!
Has anyone got a clue whats gone wrong? All business is stopped becuase we cant input lat lon. Any help would be awesome.
I am on the latest 1.x dev via cvs as of today friday feb 26 2:30pm mountain.

CommentFileSizeAuthor
#13 wkt-textfield.patch1.95 KBphayes
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

spydmobile’s picture

oops, forgot to close the code tag RATS!

spydmobile’s picture

Further, if you move the default point it does not update the WKT field. You must click a new point to get it to change.

spydmobile’s picture

While I wait for a response, I think that I will attempt to clone my entire drupal infrastructure and attempt to upgrade to 2.x dev and see if this issue remains. I will do this on Wed and post back results.

spydmobile’s picture

I was able to clone my site and force upgrade it to 2.0 which eliminates the problem, but introduces the new one of being unable to control the number of points input into the map. So this is not a solution. Anyone? Thoughts? Ideas?

tmcw’s picture

You can try pulling the code over from the old OpenLayers CCK implementation so that it does limit the number of features inputted? There's a ticket for that issue, but I'm not confident I can get on the fix within a day or two, although it could happen. If you've got some familiarity with Javascript, go for it and roll a patch.

spydmobile’s picture

thanks but I cannot and do not expect to force the issue to be resolved in 2.x (I am content to let the natural dev cycle fix it) I realize you guys are swamped but is it unrealistic to think that this 1.x issue (Which is a whole different issue) is going to be fixed in the very near future? I have to come up with a strategy as 1.x is now broken in a serious way for me.

zzolo’s picture

@spydmobile,

Updating the default value will not update any existing nodes. This is just a limitation of CCK.

I am a little confused on what the bug is. Can you describe again? Also what version where you using before where everything worked fine?

zzolo’s picture

Category: bug » support
spydmobile’s picture

Title: wkt field will not override map & default value will not go away » wkt field does not act as input field.
Category: support » bug

@zzolo
re updating exisitng nodes, ya I get that, I am saying this about NEW nodes, but that is less important than below and I will NEVER EVER mention two bugs or issues in the same ticket ever again. My Bad - I promise:

Unless you have done this intentionally, This is a bug, not a feature request.

the WKT field does not work as an input field. It did before during all my development.

When using the Openlayers widget to enter a lat lon, only the map works, not the WKT field. My modules use the map for humans and the wkt field for automation and humans.

My entire drupal system, is based on this module, a painstaking process was followed to migrate off of mapping kit to this module, and now its basic function, to input a lat long, does not work unless you click the map.

Let make this a bug and fix it please, I can test my brains out, and would be happy to try anything you suggest, but I have about 12 modules to finish writing, many of which depend on open layers and I am one man. and my fire season is coming faster than ever before in history.
Thanks for our time.
Franco

zzolo’s picture

Title: wkt field does not act as input field. » CCK Field does not handle default values display correctly

Well, no need to worry about the dual issue. It's just a way too keep tasks separated; it is appreciated, but we'll still listen.

First, I would suggest reverting back to a version of OpenLayers that did work for you if this is that critical of an issue. We cannot guarantee that we will be able to fix this within a speedy timeframe (though we try).

Second, I have just did a brief look at the behavior of the dev version.

* CCK input works as expected
* Adding a default value via PHP works, sort of:
** When adding a new node, the WKT field is populated correctly, but it does not show up on the map.
** If you save with the default, the default value shows on the map fine
** If you then edit again, it does not show on the map.
** If you update the map with new features, the features seem to show fine (and show when editing again)

So, overall, something is up with the default value and how it is displayed (as it seems to be stored just fine). I don't really know what it is at this point. This is the first time I have tried to use a default value with the CCK field, so this is why I have never noticed it. Hopefully I can look at this in more detail .

spydmobile, from the behavior I am seeing, a work-around would be to tell your users to leave the map blank to use the default value, as the value is actually stored and displayed.

spydmobile’s picture

Hi Allan, thanks.

1st, I will try reverting, but I dont hold much stock in going backwards with changes that occur on the db. I will post back my experience with that.
2nd your idea sounds well enough but it wont solve my problem, the users already have the lat lon they are trying to enter, so niether map input or saving defaults helps this. But thanks for thinking on it, I really do appreciate it.
Meanwhile, you appear to be saying that this in fact a single issue? I am unsure on that but would be happy to build a stock drupal, never enter a default and prove one way or the other if the two issues are both stemming from cck default issues.

I will post back when I have something, thanks folks
Franco

spydmobile’s picture

So, installing latest 1.x dev
create custom content type
create field called location
set it to wkt and use default map
choose 1 point, no lines or polys
save the content type and create a test node.
if you enter point(-111 60) and save the node, the new node does not have a location.
if you edit the node and set the WKT then save it, it still has no value
if you click a point on the map it has a value. if you click another, it replaces the first as it should (2.x does not do this correctly)

Since I did not change or modify default value, this issue is seperate in my mind from the trouble associated with defaults in cck
F

phayes’s picture

FileSize
1.95 KB

I can't replicate the trouble with default values. It seems to work fine for me.

However, attached is a patch for fixing the manual-wkt entry issue. It is not 100% there since we seem to be formatting multi-valued WKT wrong, but it should work for single points (which is spydmobile's issue).

zzolo’s picture

What is exactly wrong with the format?

Also, your patch looks like it inserts the WKT string as a single value in the hidden array. I think this poses problems if it is a mulitpoint or other such multi-feature entity, because this will be saved as a single value in CCK.

This has always been a tough point with CCK , in that we want to be able to represent each feature as a single value, but also use the WKT formatting to represent everything in a nice, standard way.

Maybe it is best if the public WKT input field is just a comma separated list of features instead of a nice WKT format? This makes it so that we can use the input field to actually input as we can consistently handle the values.

Unless, OpenLayers provides a way to read in a WKT value and split it up into the respective features? This would be most ideal and a lot of the code could be cleaned up. The documentation suggests this but I don't find it all that clear so I will have to test.

phayes’s picture

Assigned: Unassigned » phayes

zzolo,

OpenLayers provides a way to read in a WKT value and split it up into the respective features? This would be most ideal

That's exactly what I'm hoping to do. The patch isn't complete, but I thought I would post it in it's half-finished state for now, since it should work for spydmobile as he is only using single value fields.

phayes’s picture

What is exactly wrong with the format?

Reference:http://en.wikipedia.org/wiki/Well-known_text

Proper multipoint is: MULTIPOINT(3.5 5.6, 4.8 10.5)
We are doing: MULTIPOINT((3.5 5.6), (4.8 10.5))

zzolo’s picture

@phayes, good work. Sounds like you got a good direction. I think the bad formatting can be changed pretty easily since we put it together ourselves (not looking at the code right at the moment).

spydmobile’s picture

@phayes Thank-you thank-you thank-you perfect temp fix for me.
@zzolo Ok, I have no idea how it happened but somehow reverting versions screwed up OL to the point that it would not even show the default preset map. I deleted the entire module folder and freshly checked out the latest 6.1.x dev and the applied Patrick's changes and viola, I am back in business. I am overriding defaults and entering points via the WKT filed and I am ready for Fire season.

When things settle down for you guys, which knowing my luck will be in the height of Fire-season, I need to discuss my 1.x exit strategy with you. perhaps I can email you each a half-sack of brews and we can teleconference about it.
Regardless. thank you all for trying so hard to get me back up. Your names will be on the lips of quite a few Fire Dogs this season, praising you and thanking you.

tmcw’s picture

Any movement on this ticket? I'm not in the know enough to mark this as fixed, but it seems like this is done and has turned into different tasks.

zzolo’s picture

Priority: Critical » Normal
Status: Active » Needs work

I just stared at this for a bit. Well, the problem is that we want to read from the input field and pass it along to our data structure. And how things currently work is that the input field is actually a nice output of what is stored, which is each feature in an array and does not support reading from it. The main goal of this was to avoid having to parse WKT into individual features.

So, ideally OpenLayers would have a way to parse WKT into individual features, but I can't really find a way to do this at the moment. This would make it simple to pass values across formats.

The other approach is to be able to parse WKT ourselves which sounds annoying as its a weird format that uses different characters to delimit different things. Maybe someone has already written a parser.

Annoying at best. I'll need more time for this one.

spydmobile’s picture

Ok, fellas, I WILL NOT update my openlayers module until I know that the fix in #13 above makes into code code somewhere.
F

zzolo’s picture

Please note that the patch in #13 is not good enough to cover all the various cases. Also, the 1.x development has fallen wayside. We encourage and welcome patches.

tmcw’s picture

Status: Needs work » Closed (won't fix)

Okay, this is a half-year old. It simply isn't going to happen. 2.x or bust.