Hi Martin On the choice of memory?geometry=point... Vs point?.., at the moment both are supported.
I guess I lean towards the memory?geometry=... because I think it better follows the natural understanding of a url, in that the path defines the location, and the query string defines attributes. That said, "memory" is perhaps more properly the authority part of a URL (ie memory://?geometry=point)! One other point in favour of encoding the geometry type in the query string is that (in principle) the path component of the Url could be tampered with by the code for handling absolute/relative paths when the project is saved/reloaded, whereas the query string should not be. I'm not strongly attached to either alternative. On using the provider datasourceUri() rather than caching this in QgsVectorLayer(). It seems to me more logical that the provider owns the Uri by which it can be recreated, and which it understands. The QgsVectorLayer has no understanding of the Uri - it just passes it through to the provider, so why should it assume it will not change. In terms of the memory layer URI, even if the layer was set up with the new Uri format, including fields etc, it will not include fields a user may have added or removed manually after creating the layer. On setting the delimited text CRS in the plugin user interface. I chose not to mainly out of laziness/other priorities! Of course the CRS can still be set through the interface, at least for the layer (rather than the provider). It remains an option for future implementation :-) Cheers Chris -----Original Message----- From: Martin Dobias [mailto:[email protected]] Sent: Thursday, 20 January 2011 8:51 a.m. To: Chris Crook Cc: [email protected] Subject: Re: [Qgis-developer] Cleanly create memory layer in Python? Hi Chris On Mon, Jan 17, 2011 at 10:00 PM, Chris Crook <[email protected]> wrote: > I've added submitted a patch to implement this change at > http://trac.osgeo.org/qgis/ticket/3414. > > Changes made are: > > * QgsCoordinateReferenceSystem? string constructor has been > generalised to allow string formats > epsg:1234 > postgis:1234 > internal:1234 > proj4:proj_4_string > wkt:wkt_string > wkt_string > This is implemented by a createFromString function, similar to the > createFromId function Looks good! > * Changed QgsMemoryProvider URI format to: > > memory?geometry=Point&index=yes&crs=epsg:1234&field=id:integer&field=n > ame:string(25) I would probably prefer to have uri "point?...." instead of "memory?geometry=point&..." since the fact that we are using memory provider is given as another parameter to the vector layer constructor, so in future we would save some typing ;-) > The URI can contain the following items: > > geometry=Point|LineString|Polygon|MultiPoint|MultiLineString|MultiPoly > gon > index=yes - creates a spatial index > crs=... - defines the CRS in one of the formats above > field=definition - defines an attribute field. > > The field definition is a field name, optionally followed by > :type(length,precision), where type is one of integer, int, real, > double, and string (int/integer are synonyms, as are real/double). Eg > field=magnitude:real(16,2) > field=owner:string(64) > field=owner > > This uses Qurl for encoding and decoding the strings. To provide > backwards compatibility, if there is no geometry query string field, > then the path is taken as the geometry type. For example > point > point?crs=epsg:1234 Good. > * Added an option crs=xxxx to the QgsDelimitedTextProvider URI, so that > plugin code can specify the CRS when creating a delimited text layer. The > crs can be any of the formats listed above. Also updated the provider to use > Qurl for encoding and decoding the URI, to ensure consistent handling of > special characters. > > * Made a couple of small fixes to the QgsMemoryProviderPlugin UI > component to ensure that it correctly remembers the last choice of > delimiter type (and to encode the data source URI using Qurl) Then it would be also great to have the possibility to set CRS in the GUI... > One thing I haven't done is to modify the handling of datasourceUri in > QgsVectorLayer to ensure that it always uses the datasourceUri from the > provider, rather than storing its own version when the layer is created (or > the provider is reset). I'm not sure how safe this would be - that is > whether all the data providers correctly handle the datasourceUri() function. > I think this would be the right thing to do though - I think that the > provider should be responsible for its own URI. Any comments on the wisdom > of changing this would be welcome! Currently I don't really like this idea. It's not usual that data source URI would change inside the provider, so I would be happy to keep the current situation. Developers can be advised to use the new syntax (after all it's less verbose) and we have no problems. Regards Martin ______________________________________________________________________________________________________ This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [email protected]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank you. ______________________________________________________________________________________________________ _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
