Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread Komяpa 
Yes, but after you do such a select, you can't save this simplified line
back to OSM.

Is it different from

SELECT tags,
ST_AsGeoJSON(ST_SimplifyPreserveTopology(ST_RemoveRepeatedPoints(way,
1000), 1)) from planet_osm_polygon where name='United States of
America' and boundary='administrative';

In osm2pgsql imported with --hstore-all key?

ср, 16 нояб. 2016 г. в 7:30, RTOSM DOOPAS :

> Yes, osm2pgsql/imposm are very useful tool.
>
> While the osm2pgsql and imposm are used to import data from API
> Database to a PostGIS instance. With the PostGIS, user can perform
> tile rendering or geospatial computing.
>
> The purpose of the osm2pgsql/imposm is different. rtosm aims to make
> the API database more flexible and versatile to have the ability to
> answer following queries :
>
> "select the national boundary of U.S. in 1000 (or any other number,
> you name it) nodes and tell the simplification error of it"
>
> So user can draw any huge features in real-time in browser or JOSM
> with its simplified version. the online data editing and online data
> viewing can be more efficient.
>
> let's take an example, The relation with ID 6038068 (islands of
> Britain)  is comprised by 4596 ways and 634414 nodes. without
> simplification, even with a naive simplification which only preserve
> the start and end point of of each way will result in 4596 nodes to
> represent the feature, it is hard to visualized and manipulated with
> so many nodes retrieved from database. The rtosm can simplify the
> relation with any number of nodes.
>
> In short, rtosm is about to extend the OSM API to make it support
> viewing and editing data at any scale directly from database.
>
> On Wed, Nov 16, 2016 at 6:36 AM, Darafei "Komяpa" Praliaskouski
>  wrote:
> > Hi!
> >
> > Have you tried osm2pgsql and/or imposm? What is the reason to do it over
> API
> > db schema?
> >
> > вт, 15 нояб. 2016 г. в 19:27, RTOSM DOOPAS :
> >>
> >> Hi,
> >>
> >>
> >>
> >> I have written a small extension for OSM API database to offer the
> >> functionality of real-time simplification of objects (ways, relations)
> by
> >> node filtering during the query processing. The idea behind it is as
> >> followings:
> >>
> >>
> >> 1. For each spatial object such as way or relation, attach weight value
> to
> >> each component node by geometric computation.
> >>
> >>
> >> 2. In processing query, only retrieve nodes with the top k weight.
> >>
> >>
> >> 3. Assembly the simplified objects with filtered nodes.
> >>
> >>
> >>
> >> In fact, there are some really complex concepts, algorithms and data
> >> structures in the extension, but the essential idea is that simple.
> >>
> >>
> >> With this extension, The OSM API database will have the ability to
> answer
> >> windowing query with arbitrary size by a “top k” operator to limit the
> >> output volume of the results.
> >>
> >>
> >> The purpose of the extension is to make the OSM API database can serve
> >> data in any scale like the tile server can do.
> >>
> >>
> >>  The codes in the extension is a bit of preliminary. However, to make
> the
> >> idea work, Not only the code need to be examined and tested, but also
> the
> >> database must be “normalized” to take the advantages of this extension.
> >>
> >>
> >> The code is hosted in github, https://github.com/rtosm/rtosm
> >>
> >>
> >> The "rtosm" means a database for real-time openstreetmap. Welcome to
> >> comment.
> >>
> >> ___
> >> dev mailing list
> >> dev@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/dev
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread Christoph Hormann 
On Wednesday 16 November 2016, RTOSM DOOPAS wrote:
>
> In short, rtosm is about to extend the OSM API to make it support
> viewing and editing data at any scale directly from database.

The OSM API's main purpose is two way data transfer in small chunks.  
Since you modify the geometry this rules out any editing and 
transferring data back.

For rendering/viewing your concept hinges on the idea that dropping 
nodes is a good way to simplify geometries for rendering purposes which 
is not generally the case.  Or in other words - you assume that your 
error metric accurately describes the perceptual error when viewing the 
rendered geometry (which is evidently not the case).

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread RTOSM DOOPAS 
The simplified line is not 'saved' in the database, It is assembled
from selected nodes on-the-fly.

The rtosm extension will add several tables to the OSM API database
and do some computation on the ways and relations to derive a weight
for each node. The weight of each node will be used to determine which
node can be selected to assemble a way or relation.

The rtosm query processing is much like the original API v0.6 map call:

The original map call:

1. First the bounding box (bbox) is checked to make sure that it is sane.
2. All nodes in the bbox are searched,
3. All the ways that reference those nodes are found.
4. All Nodes that are referenced by those ways are fetched and added
to the list of nodes.
5. All the relations that reference the already found nodes and ways
are fetched.
6. All the nodes and ways that are referenced by those ways are fetched.
7. Finally all the xml is returned.

The rtosm map call (not that exact, but the framework is clear):

1. no need to check the bbox size, but need the user specified how
many nodes he/her want received to represent the bbox area.
2. A top k query in the bbox is issued to select the k nodes according
to their weight.
3.  All the ways that reference those nodes are found.
4.  All Nodes that are ancestor node (ancestor node is a concept in
tree structure which is used to represent a spatial object such as way
or relation) of already found nodes are found.
5. Ways/relations are assembled by found nodes. They are the simplified objects.
6. send back the  simplified objects to request.

.

And yes, the ST_SimplifyPreserveTopology can simplify an object by
applying Douglas-Peucker algorithm. But it needs firstly to fetch the
whole object from storage before the alogrithm can pick some nodes
from it. It cost too much to  read a large object from storage. The
better solution is to fetch only needed nodes with enough weight.

rtosm is an extension for Postgresql database without a PostGIS extension.

On Wed, Nov 16, 2016 at 5:52 PM, Darafei "Komяpa" Praliaskouski
 wrote:
> Yes, but after you do such a select, you can't save this simplified line
> back to OSM.
>
> Is it different from
>
> SELECT tags,
> ST_AsGeoJSON(ST_SimplifyPreserveTopology(ST_RemoveRepeatedPoints(way, 1000),
> 1)) from planet_osm_polygon where name='United States of America' and
> boundary='administrative';
>
> In osm2pgsql imported with --hstore-all key?
>
> ср, 16 нояб. 2016 г. в 7:30, RTOSM DOOPAS :
>>
>> Yes, osm2pgsql/imposm are very useful tool.
>>
>> While the osm2pgsql and imposm are used to import data from API
>> Database to a PostGIS instance. With the PostGIS, user can perform
>> tile rendering or geospatial computing.
>>
>> The purpose of the osm2pgsql/imposm is different. rtosm aims to make
>> the API database more flexible and versatile to have the ability to
>> answer following queries :
>>
>> "select the national boundary of U.S. in 1000 (or any other number,
>> you name it) nodes and tell the simplification error of it"
>>
>> So user can draw any huge features in real-time in browser or JOSM
>> with its simplified version. the online data editing and online data
>> viewing can be more efficient.
>>
>> let's take an example, The relation with ID 6038068 (islands of
>> Britain)  is comprised by 4596 ways and 634414 nodes. without
>> simplification, even with a naive simplification which only preserve
>> the start and end point of of each way will result in 4596 nodes to
>> represent the feature, it is hard to visualized and manipulated with
>> so many nodes retrieved from database. The rtosm can simplify the
>> relation with any number of nodes.
>>
>> In short, rtosm is about to extend the OSM API to make it support
>> viewing and editing data at any scale directly from database.
>>
>> On Wed, Nov 16, 2016 at 6:36 AM, Darafei "Komяpa" Praliaskouski
>>  wrote:
>> > Hi!
>> >
>> > Have you tried osm2pgsql and/or imposm? What is the reason to do it over
>> > API
>> > db schema?
>> >
>> > вт, 15 нояб. 2016 г. в 19:27, RTOSM DOOPAS :
>> >>
>> >> Hi,
>> >>
>> >>
>> >>
>> >> I have written a small extension for OSM API database to offer the
>> >> functionality of real-time simplification of objects (ways, relations)
>> >> by
>> >> node filtering during the query processing. The idea behind it is as
>> >> followings:
>> >>
>> >>
>> >> 1. For each spatial object such as way or relation, attach weight value
>> >> to
>> >> each component node by geometric computation.
>> >>
>> >>
>> >> 2. In processing query, only retrieve nodes with the top k weight.
>> >>
>> >>
>> >> 3. Assembly the simplified objects with filtered nodes.
>> >>
>> >>
>> >>
>> >> In fact, there are some really complex concepts, algorithms and data
>> >> structures in the extension, but the essential idea is that simple.
>> >>
>> >>
>> >> With this extension, The OSM API database will have the ability to
>> >> answer
>> >> windowing query with arbitrary size by a “top k” operator to limit the
>> >> output volume of t

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread RTOSM DOOPAS 
No modify on geometry. No modify on the 63 tables/sequences an
OpenStreetMap API Database  holds.

Only some auxiliary tables are created along the existing tables.

all the simplified objects are created on-the-fly during the query processing.

Yes, and absolutely, simplify object by geometric characteristics is
not that fine for cartographers. but as long as there are requirements
for simplified spatial object, a hand-crafted simplified object can
also be incorporated into the extension, which means the weight of
nodes is given by human not by some computational geometry algorithms.



On Wed, Nov 16, 2016 at 6:41 PM, Christoph Hormann  wrote:
> On Wednesday 16 November 2016, RTOSM DOOPAS wrote:
>>
>> In short, rtosm is about to extend the OSM API to make it support
>> viewing and editing data at any scale directly from database.
>
> The OSM API's main purpose is two way data transfer in small chunks.
> Since you modify the geometry this rules out any editing and
> transferring data back.
>
> For rendering/viewing your concept hinges on the idea that dropping
> nodes is a good way to simplify geometries for rendering purposes which
> is not generally the case.  Or in other words - you assume that your
> error metric accurately describes the perceptual error when viewing the
> rendered geometry (which is evidently not the case).
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread Paul Norman 


On 11/16/2016 5:37 AM, RTOSM DOOPAS wrote:

The rtosm map call (not that exact, but the framework is clear):

[...]
6. send back the  simplified objects to request.


The purpose of the API and the apidb is for editing. How would someone 
edit the simplified object?


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] iD 2.0.0 always start in whole world view

2016-11-16 Thread markus schnalke 
Hoi,

great that iD 2.0.0 already is available on osm.org! :-)

But I encountered a problem: When I click on the ``edit with iD''
link in keepright.at, the new iD 2.0.0 on osm.org does not (as
before) zoom to the given location but always starts in the
minimal zoom level, showing the whole world.

The link in keepright.at for instance is:

http://www.openstreetmap.org/edit?editor=id&lat=48.5398992&lon=9.9190626&zoom=18&way=24340343


meillo

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] iD 2.0.0 always start in whole world view

2016-11-16 Thread Bryan Housel 
Thanks markus!  we’re tracking this on 
https://github.com/openstreetmap/iD/issues/3588 

This is a bug in the code that hands off control from the openstreetmap-website 
code to iD which runs in an iframe..


> On Nov 16, 2016, at 6:26 PM, markus schnalke  wrote:
> 
> Hoi,
> 
> great that iD 2.0.0 already is available on osm.org! :-)
> 
> But I encountered a problem: When I click on the ``edit with iD''
> link in keepright.at, the new iD 2.0.0 on osm.org does not (as
> before) zoom to the given location but always starts in the
> minimal zoom level, showing the whole world.
> 
> The link in keepright.at for instance is:
>   
> http://www.openstreetmap.org/edit?editor=id&lat=48.5398992&lon=9.9190626&zoom=18&way=24340343
> 
> 
> meillo
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

2016-11-16 Thread RTOSM DOOPAS 
Yes, Paul. The simplified object's geometry can't be edited but we can
tell which object is simplified and which is not. in a client-side
map, some objects are simplified and some are not. The un-simplified
object can be edit.

Let's imagine a use scenario:

1. Initially, User opens JOSM/Potlatch to browse an overview map.
currently the data are shown in slippy maps which are rendered from
data to an imagery in advance at a rendering server. With rtosm, the
overview map can be a collection of simplified objects to be rendered
in client window. With this data, user can edit non-geometric part of
the object, such as tags and relation members.

2. when user zooms in, the map data retrieved from database are more
detailed. some object in previous view-window will become from
simplified to un-simplified. When an object is uneditable, user need
to zoom in more times to get its original node list.

rtosm aims to speedup data editing by offer user the ability to view
object(simplified or un-simplifed) at any scale with the constraint
that not all objects are editable, unless you zoom in enough to limit
the number of objects in the view.

Bad news is: The data editor such as JOSM/Potlatch need to change to
adapt the rtosm served data.

On Thu, Nov 17, 2016 at 3:49 AM, Paul Norman  wrote:
>
> On 11/16/2016 5:37 AM, RTOSM DOOPAS wrote:
>>
>> The rtosm map call (not that exact, but the framework is clear):
>>
>> [...]
>> 6. send back the  simplified objects to request.
>
>
> The purpose of the API and the apidb is for editing. How would someone edit
> the simplified object?
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev


On Wed, Nov 16, 2016 at 11:49 AM, Paul Norman  wrote:
>
> On 11/16/2016 5:37 AM, RTOSM DOOPAS wrote:
>>
>> The rtosm map call (not that exact, but the framework is clear):
>>
>> [...]
>> 6. send back the  simplified objects to request.
>
>
> The purpose of the API and the apidb is for editing. How would someone edit
> the simplified object?
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev