I have a PostGIS table with POLYGONs that I need to do some cleanup editing on in QGIS. However even a simple edit like deleting a vertex is saving the result back as a MULTISURFACE.
I am using QGIS 3.16.
How do I instruct QGIS to use the simplest geometry type that can represent the edited polygon?
I just ran into this issue and found your question. I think what is happening is geom columns that are generic "geometry" types are forcing QGIS to guess and/or convert the edited geometry in these columns to multisurface - I still don't know why.
To get around this, I created a new column and forced it to be multipolygon type:
alter table schema.table_name
add geom_mult geometry (Multipolygon, 4326);
Then populate my old geom column of 'mixed' geometries into this new column using ST_Multi(geom) to convert them:
update
schema.table_name
set geom_mult = ST_Multi((ST_Dump(ST_Multi(geom))).geom);
From there, I went back into QGIS and added the new table_name.geom_mult to my project. I went through the exact same editing scenarios that were causing the conversion to multisurface, and it is not converting them anymore - the polygons are all staying multipolygon - this includes topological editing using 'reshape surface' tasks and creating new singlepart polygons (qgis/postgis is storing them automatically as multipart).
So now I'm going to drop my old geom column, create a new one of multipolygon type, and re-add my converted multipolygons to this new column using an UPDATE. All my applications that expect a column called geom work just fine. I can change my QGIS layer definition to use MultiPolygon instead of Polygon (or MultiSurface depending on how QGIS read it when you added the layer).
Also I'm doing all this using multipolygon instead of just polygon as I do indeed have multipolygon data in my table, in addition to singlepart polygons. No one (QGIS, PostGIS) seems to care if singlepart polygons are stored as multipart features that I can tell.
Related
The example above is where I'd like to have X axis coming from dataset_1, and Value coming from dataset_2.
In PowerBI and QlikSense, this is possible because 2 tables can be related via key fields without being joined.
But it seems in Quicksight, the visual is linked to a single dataset. When I change to a different dataset, the selection automatically goes out of the visual.
Am I missing some steps or is it just not possible in Quicksight?
In QuickSight, all visuals can only make use of a single dataset. However, if you have an author/admin account, you should be able to create a new dataset joining data coming from existing datasets see Creating dataset using existing datasets.
Alternatively you can create a new dataset and join the data coming from your datasource. See Joining Data
I need some help, I have a stored procedure(SP) that contains NO parameters in SSMS. The SP generates spatial data by joining 2 tables one table containing two fields needed for labelling purposes and the other from a table that containsthe GEO field.
This SP populates spatial data in SSMS which I can view and interact with. All seems well so far...
I then use SSRS to create a data source and a dataset of the said stored procedure. Following this I create a new .rdl and insert a map choosing SQL Server spatial query as the source then selecting the stored procedure dataset. Following this SSRS attempts to join the data and I then receive the error from the Microsoft SQL Server Report Designer:
Unable to determine the spatial data type in the specified dataset field: GEO
I have searched the the internet for answers already and none suit predominately because they all refer to parameters causing the issue however my query does not contain nor pass any. I have tried the geo field as both a geography and geometry datatype no avail.
Any help or advice would be great.
I have just been playing with a Heat Map in SSRS using SQL Jason's example (http://www.sqljason.com/2012/03/heat-maps-for-ssrs-using-map-control.html).
It looks like your data doesn't have enough points. According to Teo Lachev (http://prologika.com/CS/blogs/blog/archive/2009/08/30/heat-maps-as-reports.aspx):
SQL Server describes polygons in Well-Known Text (WKT) standard
sponsored by Open Geospatial Consortium. For instance, a polygon is
described as five (surprise) points on the coordinate system, as
shown below. The fifth point is the same as the first point.
The example format you gave only had four points. The first and last are the same so there seems to be a missing point or you are not graphing rectangles. It doesn't look like the Spatial Data supports any other shapes. The Map wizard only shows rectangles in the Wizard when creating the map.
I'm creating tables in SQL Server > Diagram view, i just find it easier sometimes to do all the relationships, etc. Anyways, I was having trouble re-arranging the order of the columns while i'm in Diagram view, It thinks i want to make it a relationship/key instead of dragging the column before/after another one. It works fine when in the standard table creation screen (the re-arranging part) but not when i'm in Diagram view, why is that? Is there a way around it?
Not possible, can only Cut the row then insert the row and paste it.
I don't believe it is possible to do what you would like here. In theory, if it were to allow you to change the order of the columns it would be changing the underlying table which is not possible without dropping the table first.
I have a fact table that holds all date & time attributes as keys which links to actual DATE & TIME dimension.
When I create a cube on top of it using SSAS 2005, these datetime attributes are split into individual dimensions for the CUBE, which is OK.
Problem is when I add a new datetime attribute to the fact table, my cube doesn't accept that and would not create a new datetime dimension just like the other ones, unless I recreate the cube from scratch.
Can anyone please suggest, how can I add this new attribute separately as a dimension, without having to recreate the cube?
I'm struggling to understand your issue.
It sounds as if you are trying to add a new datetime column(fact) (referenced to your apporpriate Dimension/s attribute) to the Fact table. If so, this changes the structure of the cube and so requires that the cube be re-processed.
To qualify correct use of terminology, a Dimension contains Attributes. A Fact table contains Facts not attributes.
The following reference may be of use.
http://msdn.microsoft.com/en-us/library/aa905984(SQL.80).aspx
Re: Comments
Any structural changes need to be applied/registered within the Data Source View (DSV) in the Business Intelligence Development Studio (BIDS), prior to processing the cube. Clicking the refresh button on the DSV, should prompt you with an option to apply any discovered changes to your tables. Also, should any of your additions/modifications be to the underlying tables of Dimensions, then you may also need to add the attributes in question to the appoprirate Dimension .dim file, prior to re-processing the cube.
Hope this makes sense.
The problem usually comes because of Unknown Member and Null Processing options setup along with the snowflake schema if you have it in your cube. I figured out what the problem actually was.
If you have a case as one mentioned, then SSAS doesn't bring up the structural changes by itself when you refresh the Data source view. In my case, since it was date & time dimensions, I had to add new dimensions manually (Cube dimensions) and setting their NULL Processing options correctly (in my case UnknownMember and not Automatic).
Since it can be tad difficult to do these changes for all such new columns added to underlying fact table, you can try updating the XMLA script using Find & Replace method, carefully crafted.
I would like to cross-reference construct a distance chart similar to the one here (example is a road-distance cross-reference chart) and, ideally, store the data in SQL Server 2008 (preferably the Express version). It needs these properties / abilities
Every column has a corresponding row with the same name (ie. not misspelled like my example).
Changing the value at one Row-Column intersection would update the mirror intersection (Column-Row) or the mirror data could be ignored.
The distance-values would need to be end-user editable.
The end-user would need to be able to add, delete or rename a column/row pair.
The end-user needs to be able to sort the columns and have the rows move automatically.
There could be hundreds of pairs.
a look-up query needs to find a distance given a start & destination (Row & Column)
The distance chart is reasonably straightforward to implement in Excel. Considering this, am I better off...
Using Excel as the user editing UI and then updating an SQL 'thing' with the new data?
Using Excel as the data-source even if it means performance issues with querying the data?
Using an as-yet undiscovered stroke of genius detailed here in an answer?
Sure looks like an Excel application to me, start to end. (heh)
I can't imagine your users typing enough data in to make performance an issue. Excel will only take 32757 rows by ditto columns. If that's enough, I'd say you're golden.