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