> [... deleting for the sake of brevity ...]
>
> >> This SQL variant does not return errors, but it isn't visible in my
> >> QGIS
> > project
> >> (it's an ongoing project with about twenty layers built with PostGIS).
> >>
> >> Any advice?
> >>
> >> Should I direct this inquiry to the QGIS list?
>
On Thu, 28 Mar 2024, Regina Obe wrote:
Thank you to everyone for their contributions here; trying to get to
QGIS visibility here.
[... deleting for the sake of brevity ...]
This SQL variant does not return errors, but it isn't visible in my QGIS
project
(it's an ongoing project with about
On 2024-03-28 23:05 +0100, karsten wrote:
> - In DB manager e.g. when you run a query make sure you have a unique ID and
> the correct geometry column / return value selected
> If you do not have a unique id or are unsure use the row_number to cerate
> your own on the fly
> E.g. select *, ROW_NUMBE
> The reason is that it doesn't seem that QGIS can work w TEMP tables.
>
TEMP tables are only visible to the session that created them, so not a huge
surprise QGIS can't work with them.
I use them mostly to store intermediary results before dumping to another
table.
> From this, I want to create
Hi Max,
Possibly the QGIS user group is best but here are my 2 cents:
QGIS can both use views and direct SQl query results (e.g. via DB manager)
and display then as layers on the map.
There a is couple of things you should make sure so that this will work for
you:
- make sure the geometry as a
On Thu, 28 Mar 2024, Regina Obe wrote:
[Deleted for the sake of brevity]
Obviously, the case-based aspect of the city name can be cancelled with a
function such as UPPER(city).
I also am generous in the radius dimension setting it at 5k feet.
But my next question is how do position the cluste
> Thank you again; results are starting to come in.
>
> Apologies for starting a new thread; but the other one was getting messy.
>
> Here are the queries that I am testing:
> SELECT city, state, ST_ClusterDBScan( ST_Transform(geom,2163), eps :=
> 0.3048*5000, minpoints :=1) OVER () AS cluster_id
Thank you again; results are starting to come in.
Apologies for starting a new thread; but the other one was getting messy.
Here are the queries that I am testing:
SELECT city, state, ST_ClusterDBScan( ST_Transform(geom,2163), eps :=
0.3048*5000, minpoints :=1) OVER () AS cluster_id
INTO TEM
On Thu, 28 Mar 2024, Regina Obe wrote:
Depends where you got the data, but generally if they give you longitude
latitude Columns, then 4326 is a safe assumption and looks like you created
the geometry right too.
To Gary's point, 4326 is degree based, so no wonder you aren't getting any
meaningf
> Depends where you got the data, but generally if they give you longitude
> latitude Columns, then 4326 is a safe assumption and looks like you created
> the geometry right too.
>
> To Gary's point, 4326 is degree based, so no wonder you aren't getting any
> meaningful answers since 1000 would co
> On Thu, 28 Mar 2024, Gary Turner wrote:
>
> >
> > On 28/03/2024 12:32 pm, Max Pyziur wrote:
> >> On Wed, 27 Mar 2024, Regina Obe wrote:
> >>
> >>> That's the function I would have suggested.
> >>>
> >>> What query are you trying to run and what is the spatial reference
> >>> system id for your d
Gary Turner writes:
>> I then issue these two commands:
>> ALTER TABLE shapefiles.atp_filling_stations ADD COLUMN geom
>> geometry(Point, 4326);
>>
>> UPDATE shapefiles.atp_filling_stations SET geom =
>> ST_SetSRID(ST_MakePoint(longitude, latitude), 4326);
>>
>> So the SRS is 4326, right?
>
> Yes
12 matches
Mail list logo
