Re: [OSM-dev] OSRM on osm.org not working

[Stadin, Benjamin]

Just my personal opinion: From the three mentioned routing services in the PR 
(OSRM, GraphHopper, Mapzen) I find Mapzen to be the most open, and technically 
quite mature nowadays.

Where other solutions start to separate data and tech stack for commercial 
reasons, Mapzen seems to be still dedicated to open data and actively pushes 
open data projects like Transitland (public transportation data project). At 
least that's what they say [1], and by the first experiments I did with 
Valhalla it seems they live up to it.

Ben

[1] https://mapzen.com/products/



Am 01.10.2017 um 15:59 schrieb Tom Hughes 
>:

On 01/10/17 14:28, joost schouppe wrote:

Apparently, OSRM routing on osm.org  has been 
down for a few days. I have no idea how the implementation really works, or 
where the correct tracker would be. But I'm sure someone here knows.

See https://github.com/openstreetmap/openstreetmap-website/pull/1637.

Unfortunately the OSRM demo server that we were using was taken offline without 
any warning I think on the assumption that we would be happy to simply switch 
to using a free account on the commercial Mapbox routing platform in it's place 
but I'm reluctant to do that.

The problem is that as far as I know there aren't really any practical 
non-commercial routing solutions using OSM data that we could switch to without 
having to run our own, and that will obviously take time to arrange.

In the short term we likely need to merge that PR with a few tweaks but there 
remains a question about how we avoid giving undue promotion to one particular 
commercial solution.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
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] Legal question about attribution text on smartphone

[Stadin, Benjamin]

Simon, thanks but I'll also want to hear another feedback with somehwat more 
positive tone.

But since you mention Mapbox: They have their own logo in the lower left + a 
small info (i) button on the lower right. Tapping that (i) open a action sheet 
with OSM attribution and link. I think it's default, but not sure.

My interpretation about the OSM attribution requirements are that *any* form of 
link on size constrained devices is ok. I do not need a legal counsel, but ask 
(also in the legal-osm mailing list) about clarification if this assumption is 
correct.

If you find this too silly, then let someone else respond who can clarify about 
what OSM attribution requires and if my assumption is right or not. And who may 
have the right to adjust such statement on the OSM legal site where this is not 
exactly clear. It really isn't.

Whatever the legal requirements are - we'll fulfill them. As it stands the 
requirements aren't clear in this regard.

Cheers
Ben

Von meinem iPad gesendet

Am 23.04.2017 um 16:18 schrieb Simon Poole 
<si...@poole.ch<mailto:si...@poole.ch>>:

I hope you realize just how patently silly that post was.

But just in case you don't: you get legal advice from the counsel that you have 
engaged (and typically they will want money for that), you do not get it from a 
public developers mailing list (it is however the right place to get personal 
opinions on app design). Not only are there only a small number of people 
qualified to do so on the list, there are many legal (which you should know as 
a German company), liability and economic reasons why you will not get anything 
useful here.

You need to sit down with your counsel and go through your options and the 
associated risks and then decide what works best. Dealing with customers using 
your SDK and getting them to attribute the data sources correctly is going to 
be pain, just ask mapbox.

Simon

Am 23.04.2017 um 14:49 schrieb Stadin, Benjamin:
I need a legal advice, not a personal opinion about app design. That we need to 
show our own logo –we didn’t show it before but showed the OSM attribution 
text- has a solid legal background, which I won’t go into detail in a public 
mailing list. That we want to show only one logo on smartphones really has its 
reason also. We can show both on the iPad and Android tablets. And in our own 
apps, where we can control content and UI, we credit OSM at multiple places 
(legal or about page, as well as on the map view itself).

Cheers
Ben


Von: Simon Poole <si...@poole.ch><mailto:si...@poole.ch>
Datum: Sonntag, 23. April 2017 um 13:41
An: "dev@openstreetmap.org"<mailto:dev@openstreetmap.org> 
<dev@openstreetmap.org><mailto:dev@openstreetmap.org>
Betreff: Re: [OSM-dev] Legal question about attribution text on smartphone


IMHO mobile devs tend to substantially exaggerate the screen real estate 
scarcity. Two to three sources as text lines is clearly doable, and you don't 
really need to have separate links on the main screen itself, just show a 
common attribution screen.

And: -you- control how much you want to show your logo, it is -not- a third 
party legal requirement, no reason you can't simply live with some text if you 
believe there is not enough space.

Simon

Am 23.04.2017 um 00:26 schrieb Stadin, Benjamin:
It’s not our app, but this is an (indoor) map SDK which can be integrated into 
other native iOS and Android apps. A list (UIActionSheet on iOS) appears when 
our logo is tapped, showing multiple links (including a link to 
www.openstreetmap.org/copyright<http://www.openstreetmap.org/copyright>). 
Having our logo visible is a legal requirement also, and it wouldn’t be 
convenient to place the list with multiple legal links not associated to OSM 
behind the OSM attribution logo or text.

If we need to show two logos it would waste space for navigation controls and 
building / floor selection UI elements.

Since the map view will be used in other apps, we cannot control what is shown 
on the splash screen. We can place it there for our own apps, and ask customers 
of our SDK to place it there. But from experience this is often forgotten, and 
I’d rather prefer a permanent solution and give credit to OSM one way or 
another on the map view.

Cheers
Ben


Von: Martin Koppenhoefer <dieterdre...@gmail.com><mailto:dieterdre...@gmail.com>
Datum: Freitag, 21. April 2017 um 12:49
An: Rory McCann <r...@technomancy.org><mailto:r...@technomancy.org>
Cc: "dev@openstreetmap.org"<mailto:dev@openstreetmap.org> 
<dev@openstreetmap.org><mailto:dev@openstreetmap.org>, 
"legal-t...@openstreetmap.org"<mailto:legal-t...@openstreetmap.org> 
<legal-t...@openstreetmap.org><mailto:legal-t...@openstreetmap.org>
Betreff: Re: [OSM-dev] Legal question about attribution text on smartphone



sent from a phone

On 21. Apr 2017, at 12:10, Rory McCann 
<r...@technomancy

Re: [OSM-dev] Legal question about attribution text on smartphone

[Stadin, Benjamin]

I need a legal advice, not a personal opinion about app design. That we need to 
show our own logo –we didn’t show it before but showed the OSM attribution 
text- has a solid legal background, which I won’t go into detail in a public 
mailing list. That we want to show only one logo on smartphones really has its 
reason also. We can show both on the iPad and Android tablets. And in our own 
apps, where we can control content and UI, we credit OSM at multiple places 
(legal or about page, as well as on the map view itself).

Cheers
Ben


Von: Simon Poole <si...@poole.ch>
Datum: Sonntag, 23. April 2017 um 13:41
An: "dev@openstreetmap.org" <dev@openstreetmap.org>
Betreff: Re: [OSM-dev] Legal question about attribution text on smartphone


IMHO mobile devs tend to substantially exaggerate the screen real estate 
scarcity. Two to three sources as text lines is clearly doable, and you don't 
really need to have separate links on the main screen itself, just show a 
common attribution screen.

And: -you- control how much you want to show your logo, it is -not- a third 
party legal requirement, no reason you can't simply live with some text if you 
believe there is not enough space.

Simon

Am 23.04.2017 um 00:26 schrieb Stadin, Benjamin:
It’s not our app, but this is an (indoor) map SDK which can be integrated into 
other native iOS and Android apps. A list (UIActionSheet on iOS) appears when 
our logo is tapped, showing multiple links (including a link to 
www.openstreetmap.org/copyright<http://www.openstreetmap.org/copyright>). 
Having our logo visible is a legal requirement also, and it wouldn’t be 
convenient to place the list with multiple legal links not associated to OSM 
behind the OSM attribution logo or text.

If we need to show two logos it would waste space for navigation controls and 
building / floor selection UI elements.

Since the map view will be used in other apps, we cannot control what is shown 
on the splash screen. We can place it there for our own apps, and ask customers 
of our SDK to place it there. But from experience this is often forgotten, and 
I’d rather prefer a permanent solution and give credit to OSM one way or 
another on the map view.

Cheers
Ben


Von: Martin Koppenhoefer <dieterdre...@gmail.com><mailto:dieterdre...@gmail.com>
Datum: Freitag, 21. April 2017 um 12:49
An: Rory McCann <r...@technomancy.org><mailto:r...@technomancy.org>
Cc: "dev@openstreetmap.org"<mailto:dev@openstreetmap.org> 
<dev@openstreetmap.org><mailto:dev@openstreetmap.org>, 
"legal-t...@openstreetmap.org"<mailto:legal-t...@openstreetmap.org> 
<legal-t...@openstreetmap.org><mailto:legal-t...@openstreetmap.org>
Betreff: Re: [OSM-dev] Legal question about attribution text on smartphone



sent from a phone

On 21. Apr 2017, at 12:10, Rory McCann 
<r...@technomancy.org<mailto:r...@technomancy.org>> wrote:
So I dunno? Maybe? There could be ways around it if you don't want to include 
it on every map page. Does your app have a loading/spash screen? Including an 
attribution there, which is shown every time the app is started might meet the 
requirements.


have you seen this page?
https://wiki.openstreetmap.org/wiki/Legal_FAQ

generally, if there is enough space for your logo, there should also be for osm 
(on pages showing maps). If there's space for just one attribution, why not use 
it to attribute osm? The user will more likely be aware who you are (as he's 
using your app) than he will be that your map data comes from osm, so 
prioritizing OSM attribution seems to make sense


cheers,
Martin




___

dev mailing list

dev@openstreetmap.org<mailto:dev@openstreetmap.org>

https://lists.openstreetmap.org/listinfo/dev


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

Re: [OSM-dev] Legal question about attribution text on smartphone

[Stadin, Benjamin]

It’s not our app, but this is an (indoor) map SDK which can be integrated into 
other native iOS and Android apps. A list (UIActionSheet on iOS) appears when 
our logo is tapped, showing multiple links (including a link to 
www.openstreetmap.org/copyright). 
Having our logo visible is a legal requirement also, and it wouldn’t be 
convenient to place the list with multiple legal links not associated to OSM 
behind the OSM attribution logo or text.

If we need to show two logos it would waste space for navigation controls and 
building / floor selection UI elements.

Since the map view will be used in other apps, we cannot control what is shown 
on the splash screen. We can place it there for our own apps, and ask customers 
of our SDK to place it there. But from experience this is often forgotten, and 
I’d rather prefer a permanent solution and give credit to OSM one way or 
another on the map view.

Cheers
Ben


Von: Martin Koppenhoefer 
Datum: Freitag, 21. April 2017 um 12:49
An: Rory McCann 
Cc: "dev@openstreetmap.org" , 
"legal-t...@openstreetmap.org" 
Betreff: Re: [OSM-dev] Legal question about attribution text on smartphone



sent from a phone

On 21. Apr 2017, at 12:10, Rory McCann 
> wrote:
So I dunno? Maybe? There could be ways around it if you don't want to include 
it on every map page. Does your app have a loading/spash screen? Including an 
attribution there, which is shown every time the app is started might meet the 
requirements.


have you seen this page?
https://wiki.openstreetmap.org/wiki/Legal_FAQ

generally, if there is enough space for your logo, there should also be for osm 
(on pages showing maps). If there's space for just one attribution, why not use 
it to attribute osm? The user will more likely be aware who you are (as he's 
using your app) than he will be that your map data comes from osm, so 
prioritizing OSM attribution seems to make sense


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

Re: [OSM-dev] Evaluate layer list from CartoCSS style

[Stadin, Benjamin]

Thanks for your response. I indeed want to recreate the OSM style (or
adapt it, then recreate from that style).

Seems parsing these files would fairly simple. Though is there a default
implementation that handles the style parsing (in case I need to fetch
other style info which I do not forsee yet)?


Am 29.08.16, 05:28 schrieb "Paul Norman" unter <penor...@mac.com>:

>On 8/28/2016 8:07 AM, Stadin, Benjamin wrote:
>> we’re defining the data structure for the next version of our 3D map, a
>> basic feature of it is the indoor capability. I could write more about
>>the
>> background, but to keep it short for now: I need to generate an ordered
>> list of layers with their table names in the rendering db, so ordered
>>from
>> „bottom layer to top layer“, out of a Carto CSS style definition (e.g.
>> from the actual OSM style def.
>> https://github.com/gravitystorm/openstreetmap-carto).
>
>The typical osm2pgsql rendering database does not have layers. It has
>tables for points, lines, polygons, and one for data commonly used at
>low zooms.
>
>OpenStreetMap Carto comes with layers, but these are not layers in the
>traditional GIS sense. They are layers which are rendered and the layer
>definitions are not intended to be meaningful outside of the specific
>style. These regularly change between style versions and copying them is
>a bad idea unless you want to recreate that specific style.
>
>If you do want to do that, the style definitions are in YAML and should
>be easy to parse.
>
>___
>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] Experimenting with ClearTables, self-hosted vector tiles, and Tangram client-side rendering

[Stadin, Benjamin]

+1 for vector tile diversity. We¹re currently implementing a FlatBuffer
based tile format for our rendering needs, because we found that current
formats are often quite rendering engine specific. Though we do not want
to reinvent the wheel, and try to keep it close to OSM (where possible and
useful), but adding some additional stuff for 3D hierarchy data.

I hope I can publish the sources of it in some weeks.

Ben


Am 24.08.16, 08:30 schrieb "Paul Norman" unter :

>I've been experimenting with generating my own vector tiles and
>client-side rendering with Tangram[1] in order to figure out how to best
>write its styling language.
>
>Tangram is a GL-based renderer written by Mapzen and normally used with
>their Tilezen[2] vector tiles, but I'm interested in being able to make
>my own vector tiles and different cartographic choices. I also consider
>diversity of vector tile schemas important. I hope to avoid a situation
>where only large players in the market can get involved like we have
>right now.
>
>For a toolchain I used osm2pgsql with ClearTables[3] and Mapnik via
>Kosmtik[4] to write vector tiles. On the demo I'm serving the tiles with
>Apache but in development I used Kosmtik because it's xray functionality
>is useful. For development I worked in Tangram Play, a web-based editor
>that automatically reloads the map when you change the style.
>
>The cartography and vector tile definitions are loosely based on OSM
>Clear[5], a demo style I wrote. As it's a learning exercise I don't
>consider the style complete or free of bugs.
>
>The demo page is on my server at
>http://tangram-clear-demo.faramir.paulnorman.ca/ with the style and
>vector tile code at https://github.com/ClearTables/tangram-clear-demo.
>
>I'm not sure what direction I'm going to take next as I don't have any
>particular style goals right now, or collaborators.
>
>[1] https://mapzen.com/products/tangram/
>[2] https://mapzen.com/projects/vector-tiles/
>[3] https://github.com/ClearTables/ClearTables
>[4] https://github.com/kosmtik/kosmtik
>[5] https://github.com/ClearTables/osm-clear
>
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev


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

[OSM-dev] Evaluate layer list from CartoCSS style

[Stadin, Benjamin]

Hi, 

we’re defining the data structure for the next version of our 3D map, a
basic feature of it is the indoor capability. I could write more about the
background, but to keep it short for now: I need to generate an ordered
list of layers with their table names in the rendering db, so ordered from
„bottom layer to top layer“, out of a Carto CSS style definition (e.g.
from the actual OSM style def.
https://github.com/gravitystorm/openstreetmap-carto).

I think there is a better way than parsing the project file and style
files on my own, but I didn’t find a good starting point yet.

Thanks
Ben

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

Re: [OSM-dev] Numeric OSM tag keys

[Stadin, Benjamin]

Thanks Andy and Andy. I¹ll implement compression in another way then.

Best
Ben

Am 05.08.16, 14:06 schrieb "Andy Townsend" unter <ajt1...@gmail.com>:

>On 05/08/2016 12:51, Stadin, Benjamin wrote:
>> Hi,
>>
>> What is the allowed syntax for OSM tag keys? Is there actually a
>> restriction, like OSM tag keys must follow common variable name syntax?
>
>Not really.  You can see what tags are in use.  A search for tags
>containing "0" http://taginfo.openstreetmap.org/search?q=0 lists
>https://www.openstreetmap.org/node/2992379650 on the last page.
>
>Now obviously that's rubbish (and we can guess what the mapper actually
>meant there) but if you're consuming OSM data you'll need to be able to
>deal with keys such as that.
>
>
>Cheers,
>
>Andy
>
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev


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

[OSM-dev] Numeric OSM tag keys

[Stadin, Benjamin]

Hi,

What is the allowed syntax for OSM tag keys? Is there actually a
restriction, like OSM tag keys must follow common variable name syntax?

I’m asking because I hope there are no „integer“ / pure numeric keys
allowed for tag keys, because I want to use a static compression for most
popular key / value combinations. So in my tags table (actually I use
FlatBuffers, but for example) I’d store „0“ as key, „“ (empty string) as
value for the most popular key / value combination building=yes.

Regards
Ben

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

Re: [OSM-dev] Earth radius

[Stadin, Benjamin]

For my purpose I can ignore flattening and can assume a radius, because I
need fast math. My requirement is it must not be smaller, and it should be
consistent for conceptional reasons (but not for mathematical or
technical). 

Note that the mentioned values come from OSM (as most other maps) using a
"tile pyramid" scheme where tiles of each higher zoom level are exactly
half the size (in m / pixel) compared to the previous zoom level. So the
math behind this is much simpler.

You can check the mod_tile sources for example [1]. See that for example
tile2prjbounds() simply shifts x0 by the zoom level, and x0 is
-20037508.3428 which is the exact half of a the WGS84 radius (or
semi-major axis): 6378137 * 2 * pi = 40075016.6856 / 2 = 20037508.3428. So
these are the actual values used, which is close but not the same as on
the website.

[1] 
https://github.com/openstreetmap/mod_tile/blob/6b9611aaf763f4f776d1fd363433
aac7e25cb34b/src/gen_tile.cpp



Am 19.06.16, 03:09 schrieb "Greg Troxel" unter <g...@ir.bbn.com>:

>
>"Stadin, Benjamin" <benjamin.sta...@heidelberg-mobil.com> writes:
>
>> I indeed need to express distances in meters. This is a sinusoidal
>> grid with Varying cell resolutions, matching the length of web
>> mercator tiles at the equator.  I could use any value greater or equal
>> to the defined sphere radius, but not smaller.  To be consistent, it
>> should be equal.
>
>Things to keep in mind:
>
>  WGS84 is an ellipsoid, not a sphere.  There is a radius and
>  flattening, or alternatively different equatorial and polar radii.
>
>  "Web Mercator" or "Spherical Mercator" is not actually Mercator, and
>  is not conformal.   It projects by assuming a sphere, which isn't
>  true.  So trying to use one radius to get distances on the surface
>  from projected coordinates is not going to work well.
>
>So if you want the right answers, use proj.4, use real WGS84
>coordinates, and use the geodesic functions.
>
>If you need fast math within a local region, I would suggest computing a
>few correct values (a point, offset in easting, offest in northing) by
>going from projected back to geodetic and then calculate geodesics,
>finding out the ratio of distance to projected coords, and then building
>a local approximation function.  But if you aren't having CPU pain from
>doing it right, I would just use proj.4.


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

Re: [OSM-dev] Earth radius

[Stadin, Benjamin]

Thanks, I used the authoritative sources and made the math myself.

I believe the OSM website at [2] should be fixed accordingly. The radius used 
in the sources [1, and elsewhere] is in fact as expected the WGS_84 sphere of 
radius 6378137.0. It means the radius (which is said to be 6372.7982 km, that’s 
about 40 km missing at the equator) and tile sizes at [2] should be fixed for 
others who want to do funny things and get mislead by these values.

I also believe the degree column should be removed from the table. Because the 
tiling scheme is a tile pyramid, where the tile sizes are cut in half for each 
subsequent level. That isn't the same as cutting the degree into half as shown 
in the table. For example, the length at zoom level 19 for 0.0005° at the 
equator is 0.21742088 using haversine - and not 0.29858214 which is the value 
you get cutting the extent into halfs.

So the page should be updated to (note the different sphere and m/ pixel 
values):
sphere: 6378137.0
The math for m / pixel is:
z0: (6378137 * 2 * pi) / 256
z1: (6378137 * 2 * pi) / 256 / 2
…
Level   Degree  Aream / pixel   ~Scale
0   360 whole world 156543.033928   1:500 million
1   180 78271.5169641:250 million
2   90  39135.7584821:150 million
3   45  19567.8792411:70 million
4   22.59783.93962051:35 million
5   11.25   4891.96981025   1:15 million
6   5.625   2445.98490513   1:10 million
7   2.813   1222.99245256   1:4 million
8   1.406   611.496226281:2 million
9   0.703   wide area   305.748113141:1 million
10  0.352   152.874056571:500,000
11  0.176   area76.43702828 1:250,000
12  0.088   38.21851414 1:150,000
13  0.044   village or town 19.10925707 1:70,000
14  0.022   9.55462853  1:35,000
15  0.011   4.77731426  1:15,000
16  0.005   small road  2.38865713  1:8,000
17  0.003   1.19432856  1:4,000
18  0.001   0.59716428  1:2,000
19  0.0005  0.29858214  1:1,000

Ben

[1] 
https://github.com/openstreetmap/mod_tile/blob/6b9611aaf763f4f776d1fd363433aac7e25cb34b/src/gen_tile.cpp
[2] http://wiki.openstreetmap.org/wiki/Zoom_levels


Von: Komяpa <m...@komzpa.net<mailto:m...@komzpa.net>>
Datum: Samstag, 18. Juni 2016 um 07:38
An: Benjamin Stadin 
<benjamin.sta...@heidelberg-mobil.com<mailto:benjamin.sta...@heidelberg-mobil.com>>,
 OSM Dev List <dev@openstreetmap.org<mailto:dev@openstreetmap.org>>
Betreff: Re: [OSM-dev] Earth radius

Hi,

OSM uses EPSG:4326 for storing coordinates and EPSG:3857 for rendering.

You can get projection definitions on http://epsg.io/4326 and 
http://epsg.io/3857 respectively, or find it bundled with proj4 library that is 
widely used to deal with projection nuances.

сб, 18 июн. 2016 г. в 1:37, Stadin, Benjamin 
<benjamin.sta...@heidelberg-mobil.com<mailto:benjamin.sta...@heidelberg-mobil.com>>:
Hi,

I want to double check the earth radius used by OSM and zoom levels is
exactly 6372.7982 as said here:
http://wiki.openstreetmap.org/wiki/Zoom_levels.

I couldn¹t find this as constant in the sources yet. I¹m creating a new
storage system for vector tiles, independent of a projection.

Best
Ben


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

Re: [OSM-dev] Earth radius

[Stadin, Benjamin]

I indeed need to express distances in meters. This is a sinusoidal grid
with 
Varying cell resolutions, matching the length of web mercator tiles at the
equator. 
I could use any value greater or equal to the defined sphere radius, but
not smaller. 
To be consistent, it should be equal.

Ben



Am 18.06.16, 02:50 schrieb "Dirk-Lüder Kreie" unter <osm-l...@deelkar.net>:

>Am 17.06.2016 um 21:39 schrieb Stadin, Benjamin:
>> Hi,
>> 
>> I want to double check the earth radius used by OSM and zoom levels is
>> exactly 6372.7982 as said here:
>> http://wiki.openstreetmap.org/wiki/Zoom_levels.
>> 
>> I couldn¹t find this as constant in the sources yet. I¹m creating a new
>> storage system for vector tiles, independent of a projection.
>
>This constand is completely unnecessary for the projection itself unless
>you want to express distances in meters (or any other unit of length),
>since lat and lon are angles from the equator and meridian respectively.
>As long as you don't need a scale you can ignore the radius or set it to
>any arbitrary number (although 6372.7982 km is not a bad choice)
>
>-- 
>
>Dirk-Lüder "Deelkar" Kreie
>Bremen - 53.0901°N 8.7868°E


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

[OSM-dev] Earth radius

[Stadin, Benjamin]

Hi,

I want to double check the earth radius used by OSM and zoom levels is
exactly 6372.7982 as said here:
http://wiki.openstreetmap.org/wiki/Zoom_levels.

I couldn¹t find this as constant in the sources yet. I¹m creating a new
storage system for vector tiles, independent of a projection.

Best
Ben


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

[osmosis-dev] Truncate fails

[Stadin, Benjamin]

Hi,

I get the error below when I try to truncate the API DB. I'm using this command:

osmosis --truncate-apidb host="localhost" database="openstreetmap" 
user="$dbuser" password="$pw" validateSchemaVersion="no"

Ben

33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.45
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline complete.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Total execution time: 310 milliseconds.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.45
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
Jun 12, 2016 1:33:22 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
Jun 12, 2016 1:33:23 AM 
org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager 
waitForCompletion
SEVERE: Thread for task 1-truncate-apidb failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to execute 
statement.
at 
org.openstreetmap.osmosis.apidb.common.DatabaseContext.executeStatement(DatabaseContext.java:330)
at 
org.openstreetmap.osmosis.apidb.common.DatabaseContext.truncateTables(DatabaseContext.java:182)
at 
org.openstreetmap.osmosis.apidb.v0_6.ApidbTruncator.run(ApidbTruncator.java:58)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.postgresql.util.PSQLException: ERROR: relation 
"current_relation_members" does not exist
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:616)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:452)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:444)
at 
org.openstreetmap.osmosis.apidb.common.DatabaseContext.executeStatement(DatabaseContext.java:327)
... 3 more

Jun 12, 2016 1:33:23 AM org.openstreetmap.osmosis.core.Osmosis main
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more tasks 
failed.
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

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

[osmosis-dev] Osmosis and local data sets

[Stadin, Benjamin]

Hi,

I've a local OSM server where I've imported a city extract. I need to import 
many small areas by converting geojson files to OSM XML first, and then import 
these files into the local OSM db to allow for map edits.

I'm assigning negative numbers to the ids. But when I import the data, the 
following duplicate key error is thrown:

duplicate key value violates unique constraint "current_nodes_pkey1"
  Detail: Key (id)=(1) already exists.

There is no id=1 in my data set. Therefore I don't know where to start looking 
at.

The import command is this:
osmosis --read-xml "$out_file" \
  --write-apidb host="localhost" database="openstreetmap" \
  user="$user" password="$pw" validateSchemaVersion="no"

I'm very new to OSM, so maybe I'm doing something wrong. 

Is this the right way to import data after the initial update is done? Where 
does the duplicate key error come from?

I've also dumped a small extract of my generated OSM XML file below.

Best
Ben



...

...

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

[OSM-dev] Change settings to edit map at different zoom level

[Stadin, Benjamin]

Hi,

is there a setting which allows to control at which zoom level it's possible to 
start editing a map? I want to change my local OSM installation to allow 
editing at a lower zoom level. 

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

Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

[Stadin, Benjamin]

I've managed to install a small OSM test setup with a local instance of 
Nominatim. I can edit and save map changes via the iD editor that is bundled 
with OSM.


However, I didn't have success with using an isolated instance of iD. I've 
edited config.js as below, but I can't connect to the API.


Is it because I need a user session?


Best

Ben


protocol = useHttps ? 'https:' : 'http:',
url = protocol + '//localhost',
connection = {},
inflight = {},
loadedTiles = {},
tileZoom = 16,
oauth = osmAuth({
url: protocol + '//localhost',
oauth_consumer_key: 'xxx',
oauth_secret: 'yyy',
loading: authenticating,
done: authenticated
}),



Von: Simon Poole <si...@poole.ch>
Gesendet: Sonntag, 5. Juni 2016 23:59
An: dev@openstreetmap.org
Betreff: Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

It is probably a good idea to have a look at

http://www.asklater.com/matt/blog/2015/11/18/the-road-to-api-07/

of which cgimap and developing it further is a key piece.

Simon



Am 04.06.2016 um 18:34 schrieb Stadin, Benjamin:
Hi Bryan,

thank you for these pointers.

A somehwat unrelated question: The FAQ mentions cgimap. Is this performance 
optimized map API implementation still relevant and is it still in use? Will a 
production system benefit from this significantly, when it has to deal with 
lots of requests?

Thanks
Ben

Von: Bryan Housel <br...@7thposition.com><mailto:br...@7thposition.com>
Gesendet: Samstag, 4. Juni 2016 18:03:19
An: Stadin, Benjamin
Cc: osm-dev
Betreff: Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

Hi Ben,

iD's connection to OSM is in `connection.js`:
https://github.com/openstreetmap/iD/blob/a8ac9faad8a597d81813d8effd5cc5c1a1a0a668/js/id/core/connection.js#L8-L19

iD's connection to Nominatim is in the `nominatim.js` service:
https://github.com/openstreetmap/iD/blob/master/js/id/services/nominatim.js#L3

See also from our FAQ:
https://github.com/openstreetmap/iD/blob/master/FAQ.md#can-i-use-id-with-my-own-osm-server

Thanks, Bryan



On Jun 3, 2016, at 7:54 PM, Stadin, Benjamin 
<benjamin.sta...@heidelberg-mobil.com<mailto:benjamin.sta...@heidelberg-mobil.com>>
 wrote:

Hi list,

I¹m on a quest to setup an own instance of OSM, altogether with Nominatim
and iD editor. iD should communicate with this very instance of OSM and
not with the global OSM website.

While I¹ll continue to digg into the code, do you have some valuable
pointers for me about installing and configuring these three? While the
website is documented well, this triplet is not. It doesn¹t seem to be
common (understandably, but I really need to do this).

Cheers
Ben


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




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


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

[OSM-dev] osmosis not handling empty command line values

[Stadin, Benjamin]

Hi,

I¹m following the import example from [1] with a small extract:

osmosis --read-pbf ka.pbf \
  --write-apidb host="localhost" database="openstreetmap" \
  user="openstreetmap" password="" validateSchemaVersion="no"


But this throws an error:
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Argument 7 doesn't
contain a value after the '=' (ie. name=value).
at 
org.openstreetmap.osmosis.core.cli.CommandLineParser.parseTask(CommandLineP
arser.java:281)

The 7th argument is the password argument. When I remove that argument,
osmosis doesn¹t complain but fails to connect to the db.


The osmosis version I use is a prebuilt v0.45 from here:
http://bretth.dev.openstreetmap.org/osmosis-build/osmosis-latest.tgz

I wasn¹t able yet to compile it from sources (I¹ve Ubuntu 16.04 and Oracle
Java 8 - according to the compile errors I guess Java 7 would be better to
build the package).

I didn¹t look into the code, but it seems the "" is not treated as an
empty string but eliminated in the course.

Best
Ben

[1] 
https://github.com/openstreetmap/openstreetmap-website/blob/master/CONFIGUR
E.md


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

Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

[Stadin, Benjamin]

Hi Bryan,

thank you for these pointers.

A somehwat unrelated question: The FAQ mentions cgimap. Is this performance 
optimized map API implementation still relevant and is it still in use? Will a 
production system benefit from this significantly, when it has to deal with 
lots of requests?

Thanks
Ben

Von: Bryan Housel <br...@7thposition.com>
Gesendet: Samstag, 4. Juni 2016 18:03:19
An: Stadin, Benjamin
Cc: osm-dev
Betreff: Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

Hi Ben,

iD's connection to OSM is in `connection.js`:
https://github.com/openstreetmap/iD/blob/a8ac9faad8a597d81813d8effd5cc5c1a1a0a668/js/id/core/connection.js#L8-L19

iD's connection to Nominatim is in the `nominatim.js` service:
https://github.com/openstreetmap/iD/blob/master/js/id/services/nominatim.js#L3

See also from our FAQ:
https://github.com/openstreetmap/iD/blob/master/FAQ.md#can-i-use-id-with-my-own-osm-server

Thanks, Bryan



On Jun 3, 2016, at 7:54 PM, Stadin, Benjamin 
<benjamin.sta...@heidelberg-mobil.com<mailto:benjamin.sta...@heidelberg-mobil.com>>
 wrote:

Hi list,

I^1m on a quest to setup an own instance of OSM, altogether with Nominatim
and iD editor. iD should communicate with this very instance of OSM and
not with the global OSM website.

While I^1ll continue to digg into the code, do you have some valuable
pointers for me about installing and configuring these three? While the
website is documented well, this triplet is not. It doesn^1t seem to be
common (understandably, but I really need to do this).

Cheers
Ben


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

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

Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

[Stadin, Benjamin]

That was what my question was about, though I wasn't clear enough maybe.

Thanks for your insights,
Ben

Von: Tom Hughes <t...@compton.nu>
Gesendet: Samstag, 4. Juni 2016 11:05:23
An: Stadin, Benjamin; dev@openstreetmap.org
Betreff: Re: OSM + iD + Nominatim Setup instructions

On 04/06/16 09:19, Stadin, Benjamin wrote:

> But there seem to be some places where the Nominatim URL is hardcoded
> instead of using NOMINATIM_URL.

I'm not sure what that has to do with anything I wrote?

I mean I said nothing about integrating your instance of the rails port
with your instance of nominatim, mostly because I had no idea whether or
not it was configurable!

> For example:
> https://github.com/openstreetmap/openstreetmap-website/blob/master/lib/nomi
> natim.rb

Sure it's a bug - fixes welcome.

> https://github.com/openstreetmap/openstreetmap-website/blob/master/test/htt
> p/nominatim.yml
> (That’s a test case, but still why shouldn’t it use a configured URL to
> test the actual instance)

Well a test shouldn't be touching a live server at all. and indeed it
doesn't because that file is actual controlling the mock server that is
used in testing - it lists the URLs and the responses that will be faked
when those URLs are hit.

So the test environment will always need to use NOMINATIM_URL pointing
at the real server as that is the URL that the mocks respond to.

> Also all locale yamls (though that is less important I’d say):
> https://github.com/openstreetmap/openstreetmap-website/blob/7b96de31f7842ca
> f13da40dc71ff2d33146ad60b/config/locales/sk.yml

Again, bugs, though probably a bit harder to fix.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM + iD + Nominatim Setup instructions

[Stadin, Benjamin]

But there seem to be some places where the Nominatim URL is hardcoded
instead of using NOMINATIM_URL.

For example:
https://github.com/openstreetmap/openstreetmap-website/blob/master/lib/nomi
natim.rb

https://github.com/openstreetmap/openstreetmap-website/blob/master/test/htt
p/nominatim.yml
(That’s a test case, but still why shouldn’t it use a configured URL to
test the actual instance)

Also all locale yamls (though that is less important I’d say):
https://github.com/openstreetmap/openstreetmap-website/blob/7b96de31f7842ca
f13da40dc71ff2d33146ad60b/config/locales/sk.yml

Ben


Am 04.06.16, 08:36 schrieb "Tom Hughes" unter <t...@compton.nu>:

>On 04/06/16 00:54, Stadin, Benjamin wrote:
>
>> I¹m on a quest to setup an own instance of OSM, altogether with
>>Nominatim
>> and iD editor. iD should communicate with this very instance of OSM and
>> not with the global OSM website.
>
>If you install your own copy of the website then the builtin iD should
>do that automatically.
>
>So really it's only OSM and Nominatim you are setting up.
>
>Tom
>
>-- 
>Tom Hughes (t...@compton.nu)
>http://compton.nu/

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

Re: [OSM-dev] Simpler binary OSM formats

[Stadin, Benjamin]

> When you need relations-ways-nodes read order, blocks will save you  from 
> unnecessary read-through the whole file (yes, you can skip decompression for 
> nodes/ways but still you must read the whole file).

Or use mmap. Or directly Cap’n Proto or FlatBuffers, which support this out of 
the box.
https://capnproto.org/cxx.html#using-mmap

> Second example: find something by id, if you have blocks it's easy to map 
> whole block into memory and do a binary search for logN block reads instead 
> of seeing through a file all the time.

I believe it will make implementation unnecessary more complicated. In case of 
Cap’n Proto you could set the initial position of your binary search to the 
array index, under the hood it would use mmap to seek the location. Also you 
can improve on lookup: for example start a binary search for way with id 999 at 
ways[999] instead of ways[waysCount/2]

Von: Дмитрий Киселев 
>
Datum: Sonntag, 7. Februar 2016 um 20:10
An: Andrew Byrd >
Cc: Benjamin Stadin 
>,
 "dev@openstreetmap.org" 
>
Betreff: Re: [OSM-dev] Simpler binary OSM formats

As for fixed sized blocks in vex, I did consider that option but couldn’t come 
up with a compelling reason for it. I can see the case for a maximum block size 
(so we know what the maximum size of allocation will be), but can you give a 
concrete example of how fixed-size blocks would be advantageous in practice? I 
would be very hesitant to split any entity across multiple blocks.
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

When you need relations-ways-nodes read order, blocks will save you  from 
unnecessary read-through the whole file (yes, you can skip decompression for 
nodes/ways but still you must read the whole file).

Second example: find something by id, if you have blocks it's easy to map whole 
block into memory and do a binary search for logN block reads instead of seeing 
through a file all the time.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Simpler binary OSM formats

[Stadin, Benjamin]

Hi Andrew,

Cap'n Proto (successor of ProtoBuffer from the guy who invented ProtoBuffer) 
and FlatBuffers (another ProtoBuffer succesor, by Google) have gained a lot of 
traction since last year. Both eliminate many if the shortcomings of the 
original ProtoBuffer (allow for random access, streaming,...), and improve on 
performance also.

https://github.com/google/flatbuffers

Here is a comparison between ProtoBuffer competitors:
https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html

In my opinion FlatBuffers is the most interesting. It seems to have very good 
language and platform support, and has quite a high adoption rate already.

I think that it's well worth to reconsider creating an own file format and 
parser for several reasons. Your concept looks well thought, it should be 
possible to implement a lighweight parser using FlatBuffers for your data 
scheme.

Regards
Ben

Von meinem iPad gesendet

Am 06.02.2016 um 22:37 schrieb Andrew Byrd 
>:

Hello OSM developers,

Last spring I posted an article discussing some shortcomings of the PBF format 
and proposing a simpler binary OSM interchange format called VEX. There was a 
generally positive response at the time, including helpful feedback from other 
developers. Since then I have revised the VEX specification as well as our 
implementation, and Conveyal has been using this format in our own day-to-day 
work.

I have written a new article describing of the revised format:
http://conveyal.com/blog/2016/02/06/vex-format-part-two

The main differences are 1) it is more regular and even simpler to parse; and 
2) file blocks are compressed individually, allowing parallel processing and 
seeking to specific entity types. It is no longer smaller than PBF, but still 
comparable in size.

Again, I would welcome any comments you may have on the revised format and the 
potential for a shift to simpler binary OSM formats.

Regards,
Andrew Byrd


On 29 Apr 2015, at 01:35, andrew byrd 
> wrote:

Hello OSM developers,

Over the last few years I have worked on several pieces of software that 
consume and produce the PBF format. I have always appreciated the advantages of 
PBF over XML for our use cases, but over time it became apparent to me that PBF 
is significantly more complex than would be necessary to meet its objectives of 
speed and compactness.

Based on my observations about the effectiveness of various techniques used in 
PBF and other formats, I devised an alternative OSM representation that is 
consistently about 8% smaller than PBF but substantially simpler to encode and 
decode. This work is presented in an article at 
http://conveyal.com/blog/2015/04/27/osm-formats/. I welcome any comments you 
may have on this article or on the potential for a shift to simpler binary OSM 
formats.

Regards,
Andrew Byrd
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

___
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] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

Imforgot to saym this. The problem I have to solve is that I need to be able to 
export also to other projections. For our indoor navigation and accurate site 
maps we have to use a proper projection. Thus my idea to index WGS84 datum, and 
enble to index oberlappings efficiently. When this is solved it should be 
possible to load WGS84 data cells that overlap a world area for a given 
projection (using the bbox from input, loading overlapping MODIS cells) and cut 
the export at the bounding sites later on.

Ben

Von meinem iPad gesendet

> Am 06.01.2016 um 13:41 schrieb Andrew Byrd :
> 
> 
>> On 06 Jan 2016, at 13:13, Andrew Byrd  wrote:
>> Obviously in the long term we’ll want to improve the index to handle these 
>> cases. Both of these limitations should be straightforward to overcome. To 
>> index large polygons as areas and you’d either need some kind of multi-level 
>> index (rectangle tree or “pyramids") or just accept rasterizing area 
>> polygons into all the index cells they overlap (a polygon’s ID appearing 
>> repeatedly, in every tile it overlaps).
> 
> I should elaborate: 
> 
> Using a predefined grid is practical because you don’t need to store the 
> bounds of the index nodes (they’re regular tiles, so their bounding boxes are 
> implicit in the grid definition). You can determine which index cell any 
> element is in by just chopping low-order bits off its projected coordinates 
> to match the index’s constant zoom level.
> 
> If you’re rendering map tiles, there’s also the advantage of a 1:1 
> correspondance between one spatial index node and one output map tile at or 
> above the index’s zoom level, and a simple one-to-many relationship below 
> that zoom level. This is also practical for exporting rectangular PBF regions.
> 
> If you want to index objects physically larger than a tile in the index or 
> reflect the fact that objects span tiles, you could repeat the identifier of 
> that object in every tile it touches (what I referred to as rasterizing the 
> geometry), but this approach leads to a lot of repetition of identifiers and 
> de-duplication of identifiers when you query the index.
> 
> An alternative approach is a hierarchical index, where each index node is 
> entirely physically contained within a higher-level node. Conveniently the 
> web Mercator map tile system defines a perfectly aligned hierarchy of squares 
> via its zoom levels: it is a quad tree 
> (https://en.wikipedia.org/wiki/Quadtree). You simply index each object at the 
> highest zoom level that still contains the object entirely within one tile, 
> and when you do a query operation from the index, you can easily traverse up 
> the zoom levels without maintaining pointers between them (you can find the 
> coordinates of the next higher tile by just chopping off low order bits).
> 
> There are of course many ways to implement spatial indexes, but considering 
> that we’re working with data that often gets rendered or exported in 
> tile-sized chunks, this approach seemed well-suited to me.
> 
> I’d of course welcome any insight or suggestions that might improve our 
> implementation.
> 
> -Andrew

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

Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

And about the cell data: I'm considering to just reuse OSM pbf format, without 
preserving sort and size attributes. When exporting the data from individual 
grid cells, all data items will be streamed to the output ordered by type and 
ID. A simple in memory AVL tree should be sufficient (storing id keys and 
pointers to items as node data, iterating lowest to highest id on output).

Von meinem iPad gesendet

> Am 06.01.2016 um 13:49 schrieb Stadin, Benjamin 
> <benjamin.sta...@heidelberg-mobil.com>:
> 
> Hi Andrew,
> 
> The underlying storage looks useful indeed. My current idea is to change the 
> indexing in Vanilla Extract as follows (and later add parts from TileMaker as 
> well):
> 
> - Implement an adaptation of a MODIS grid, in order to have rectangular grid 
> cells for easier indexing and storage containers for unprojected WGS84 datum. 
> The size of the cells should be configurable, to find a sweet spot between 
> data size for reads and update pefrormance for writes (since we must rewrite 
> whole cells later on)
> - Create an in-memory rtree index for all grid cells
> - for all geometries, check during creation of the storage if they overlap 
> other cells using the rtree index. If they do overlap, write a relationship 
> info (I'll probably use SQLite db, also for the cell storage). So when you 
> load kater on extract a cell at row 18, col 20, this cell may have a 
> relationship to some cell at row 25, col 23 for example. Youd load this cell 
> as well when extracting the data
> 
> Something like this. What do you think?
> 
> Ben 
> 
> Von meinem iPad gesendet
> 
>> Am 06.01.2016 um 13:13 schrieb Andrew Byrd <and...@fastmail.net>:
>> 
>> 
>>> On 06 Jan 2016, at 03:40, Stadin, Benjamin 
>>> <benjamin.sta...@heidelberg-mobil.com> wrote:
>>> Does your Vanilla Extract consider overlapping polygons? Like if you export 
>>> a small area within a country, does it add the country's polygon that 
>>> overlaps the area? 
>>> It looks pretty interesting though. I'm not sure where to start at, yet I 
>>> thinkit will be good to combine features from TileMaker and Vanilla Extract.
>> 
>> Our spatial indexing is rather crude and tile-based. This is intentional to 
>> keep it small and simple. We have a grid of cells which correspond to the 
>> web mercator tiles at a single zoom level, and every OSM object is assigned 
>> to one tile only. This is problematic for objects that span multiple tiles. 
>> Also note that free-floating nodes which are not included in any way are not 
>> reachable using the current index. For our applications we just haven’t 
>> needed to index free-floating POI nodes yet, and don’t need large 
>> administrative borders or huge area polygons.
>> 
>> Obviously in the long term we’ll want to improve the index to handle these 
>> cases. Both of these limitations should be straightforward to overcome. To 
>> index large polygons as areas and you’d either need some kind of multi-level 
>> index (rectangle tree or “pyramids") or just accept rasterizing area 
>> polygons into all the index cells they overlap (a polygon’s ID appearing 
>> repeatedly, in every tile it overlaps).
>> 
>> So the indexing system would need some work for your application. But I 
>> thought the two underlying storage systems for OSM data could be useful to 
>> you.
>> 
>> -Andrew
> 
> ___
> 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] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

Hi Andrew,

The underlying storage looks useful indeed. My current idea is to change the 
indexing in Vanilla Extract as follows (and later add parts from TileMaker as 
well):

- Implement an adaptation of a MODIS grid, in order to have rectangular grid 
cells for easier indexing and storage containers for unprojected WGS84 datum. 
The size of the cells should be configurable, to find a sweet spot between data 
size for reads and update pefrormance for writes (since we must rewrite whole 
cells later on)
- Create an in-memory rtree index for all grid cells
- for all geometries, check during creation of the storage if they overlap 
other cells using the rtree index. If they do overlap, write a relationship 
info (I'll probably use SQLite db, also for the cell storage). So when you load 
kater on extract a cell at row 18, col 20, this cell may have a relationship to 
some cell at row 25, col 23 for example. Youd load this cell as well when 
extracting the data

Something like this. What do you think?

Ben 

Von meinem iPad gesendet

> Am 06.01.2016 um 13:13 schrieb Andrew Byrd <and...@fastmail.net>:
> 
> 
>> On 06 Jan 2016, at 03:40, Stadin, Benjamin 
>> <benjamin.sta...@heidelberg-mobil.com> wrote:
>> Does your Vanilla Extract consider overlapping polygons? Like if you export 
>> a small area within a country, does it add the country's polygon that 
>> overlaps the area? 
>> It looks pretty interesting though. I'm not sure where to start at, yet I 
>> thinkit will be good to combine features from TileMaker and Vanilla Extract. 
> 
> Our spatial indexing is rather crude and tile-based. This is intentional to 
> keep it small and simple. We have a grid of cells which correspond to the web 
> mercator tiles at a single zoom level, and every OSM object is assigned to 
> one tile only. This is problematic for objects that span multiple tiles. Also 
> note that free-floating nodes which are not included in any way are not 
> reachable using the current index. For our applications we just haven’t 
> needed to index free-floating POI nodes yet, and don’t need large 
> administrative borders or huge area polygons.
> 
> Obviously in the long term we’ll want to improve the index to handle these 
> cases. Both of these limitations should be straightforward to overcome. To 
> index large polygons as areas and you’d either need some kind of multi-level 
> index (rectangle tree or “pyramids") or just accept rasterizing area polygons 
> into all the index cells they overlap (a polygon’s ID appearing repeatedly, 
> in every tile it overlaps).
> 
> So the indexing system would need some work for your application. But I 
> thought the two underlying storage systems for OSM data could be useful to 
> you.
> 
> -Andrew
> 

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

Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

I think for exporting data of a given area, the cell based spatial splitting 
will outperform any database solution that treats individual geometries by an 
order of magnitude. But I think you are right about PBF being too simple, 
random access issues and updateability. 

I still think that a clever block handling would work well for both extracts 
and updates. 
What do you think about changing vex files to use offset pointers for it's 
data, and a fill factor of say 10-20 percent? 
So the initial cell size would be 20% larger on disk, change set data would 
mean to simply unlink the offset and append data to the current offset. When 
growing too large, a new file would be generated with again 20% additional 
space for change sets. 
Is there any data missing from the vex file format, or is all included from OSM 
pbf? 

Ben

Von meinem iPad gesendet

> Am 06.01.2016 um 15:14 schrieb Andrew Byrd <and...@fastmail.net>:
> 
> 
>> On 06 Jan 2016, at 14:10, Stadin, Benjamin 
>> <benjamin.sta...@heidelberg-mobil.com> wrote:
>> 
>> And about the cell data: I'm considering to just reuse OSM pbf format, 
>> without preserving sort and size attributes. When exporting the data from 
>> individual grid cells, all data items will be streamed to the output ordered 
>> by type and ID. A simple in memory AVL tree should be sufficient (storing id 
>> keys and pointers to items as node data, iterating lowest to highest id on 
>> output)
> 
> We wanted to preserve conventional entity ordering (node, way, relation) but 
> maintaining increasing ID number was not important for us; I preferred a 
> constant-memory export process (i.e. memory consumption does not grow with 
> the geographic size of the extract) that simply iterates over index cells in 
> order three times, dumping first nodes, then ways, then relations.
> 
> If I understand you correctly you’d use the PBF format as your internal 
> storage format, making one PBF file per spatial index cell (essentially 
> splitting planet.pbf into one PBF file per tile). I can see the appeal of 
> simplicity here, and I considered this approach myself, but I think PBF would 
> be problematic if you intend to perform random access within those tiles to 
> apply minutely updates. PBF is a data interchange format, to my knowledge 
> designed and used primarily for moving or streaming database dumps or 
> extracts from one site to another. You’ll end up doing a lot of 
> decompress-filter-modify-rewrite operations on entire tiles. It could work, 
> but it seems awkward and resource intensive. I can also imagine running into 
> some problems with a 1 to N geographic PBF splitter. Due to PBF's block-based 
> nature you might have to keep a prohibitively large number of files open 
> simultaneously during your planet-to-tile splitter step. If the planet.pbf 
> must pass through some intermediate representation to allow splitting 
> (essentially a spatially indexed database of some kind), why not keep it in 
> that intermediate representation and perform the spatial splitting on demand.
> 
> -Andrew
> 

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

Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

Thank you. This is enough clarification for me. Then I’ll create an independent 
store (using OSM PBF format but using spatial clustering) and on export the 
required order for the region will be recreated.

Von: Paul Norman <penor...@mac.com<mailto:penor...@mac.com>>
Datum: Dienstag, 5. Januar 2016 um 18:09
An: "dev@openstreetmap.org<mailto:dev@openstreetmap.org>" 
<dev@openstreetmap.org<mailto:dev@openstreetmap.org>>
Betreff: Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

On 1/5/2016 8:32 AM, Stadin, Benjamin wrote:
I’m thinking about a design for an efficient storage container for OSM PBF 
(planet size data, minutely updates), for the purpose of TileMaker as well as 
for an internal application.

Good to see Tilemaker (https://github.com/systemed/tilemaker) getting some 
traction.

One thing I stumbled on is the usage of the bounding boxes within OSM PBF. The 
documentation [1] does not clarify on the spatial characteristics of the 
individual FileBlocks. Some questions:

  1.  Is it correct that there is exactly one HeaderBlock in a .pbf file? If 
so, the BBOX defined within the HeaderBlock defines the whole region of the 
.pbf export?
  2.  What are the spatial characteristics of an individual FileBlock within 
the FileBlocks sequence? Is a FileBlock generated by any kind of spatial 
ordering? For example, is it save to assume that all content is very dense / 
close to a region of the world? Or can this be controlled when creating a .pbf? 
If there was a spatial loose relationship, it would allow to relate FileBlocks 
to map „tile“ regions (a FileBlock may obviously relate to several „tiles“, but 
would be fine as long as the blocks relate to a certain region for most of it’s 
content)
  3.  There is a commented BBOX definition within the PrimitiveBlock. What 
remains to be done to to enable this proposed BBOX extension? I’d have the same 
question about this BBOX as with my second question.

PBFs are generally ordered by type then ID, so there is no guaranteed spatial 
clustering. There is a strong correlation between nearby IDs and objects being 
near each other which makes delta encoding worthwhile.

A lot of software implicitly depends on ordering. Sorting by type is often a 
hard requirement - doing anything with ways normally requires having parsed all 
the nodes for geometries. Sorting by ID may be needed depending on how storage 
algorithms were implemented - software can become less efficient or break if 
it's expecting ordered IDs and gets unordered.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

I’m thinking about a design for an efficient storage container for OSM PBF 
(planet size data, minutely updates), for the purpose of TileMaker as well as 
for an internal application.

One thing I stumbled on is the usage of the bounding boxes within OSM PBF. The 
documentation [1] does not clarify on the spatial characteristics of the 
individual FileBlocks. Some questions:

  1.  Is it correct that there is exactly one HeaderBlock in a .pbf file? If 
so, the BBOX defined within the HeaderBlock defines the whole region of the 
.pbf export?
  2.  What are the spatial characteristics of an individual FileBlock within 
the FileBlocks sequence? Is a FileBlock generated by any kind of spatial 
ordering? For example, is it save to assume that all content is very dense / 
close to a region of the world? Or can this be controlled when creating a .pbf? 
If there was a spatial loose relationship, it would allow to relate FileBlocks 
to map „tile“ regions (a FileBlock may obviously relate to several „tiles“, but 
would be fine as long as the blocks relate to a certain region for most of it’s 
content)
  3.  There is a commented BBOX definition within the PrimitiveBlock. What 
remains to be done to to enable this proposed BBOX extension? I’d have the same 
question about this BBOX as with my second question.

message PrimitiveBlock {
   ….
// Proposed extension:
  //optional BBox bbox = 19;
}

I’d add an additional parse step to create this spatial relationship, if there 
is no spatial relationship yet or the spatial characteristics are not „good 
enough“.

~Ben

[1] http://wiki.openstreetmap.org/wiki/PBF_Format
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

One more question:
4) The documentation says: "The current serializer 
(Osmosis) preserves the order of 
OSM entities, and tags on OSM entities."
What would be the downside if this order was lost (when the FileBlocks are 
recreated in a custom spatial order)?


Von: Benjamin Stadin 
>
Datum: Dienstag, 5. Januar 2016 um 17:32
An: "dev@openstreetmap.org" 
>
Betreff: [OSM-dev] OSM PBF and spatial characteristics of blocks

I’m thinking about a design for an efficient storage container for OSM PBF 
(planet size data, minutely updates), for the purpose of TileMaker as well as 
for an internal application.

One thing I stumbled on is the usage of the bounding boxes within OSM PBF. The 
documentation [1] does not clarify on the spatial characteristics of the 
individual FileBlocks. Some questions:

  1.  Is it correct that there is exactly one HeaderBlock in a .pbf file? If 
so, the BBOX defined within the HeaderBlock defines the whole region of the 
.pbf export?
  2.  What are the spatial characteristics of an individual FileBlock within 
the FileBlocks sequence? Is a FileBlock generated by any kind of spatial 
ordering? For example, is it save to assume that all content is very dense / 
close to a region of the world? Or can this be controlled when creating a .pbf? 
If there was a spatial loose relationship, it would allow to relate FileBlocks 
to map „tile“ regions (a FileBlock may obviously relate to several „tiles“, but 
would be fine as long as the blocks relate to a certain region for most of it’s 
content)
  3.  There is a commented BBOX definition within the PrimitiveBlock. What 
remains to be done to to enable this proposed BBOX extension? I’d have the same 
question about this BBOX as with my second question.

messagePrimitiveBlock {
   ….
// Proposed extension:
  //optional BBox bbox = 19;
}

I’d add an additional parse step to create this spatial relationship, if there 
is no spatial relationship yet or the spatial characteristics are not „good 
enough“.

~Ben

[1] http://wiki.openstreetmap.org/wiki/PBF_Format
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM PBF and spatial characteristics of blocks

[Stadin, Benjamin]

Hi Andrew,

My goal is to implement or extend something like TileMaker+Vanilla Extract+X. I 
need a fast and reliable tool that can generate image tiles and (custom) vector 
tiles for client side rendering as well as map extracts for small user-editable 
maps. 
The X part will be for our own 3D renderer for internal use (to create object 
hierarchies, there are no layers but a hierarchy of objects in the 3D scene 
graph).

Does your Vanilla Extract consider overlapping polygons? Like if you export a 
small area within a country, does it add the country's polygon that overlaps 
the area? 
It looks pretty interesting though. I'm not sure where to start at, yet I 
thinkit will be good to combine features from TileMaker and Vanilla Extract. 

Ben

Von meinem iPad gesendet

Am 05.01.2016 um 19:46 schrieb Andrew Byrd :

>> On 05 Jan 2016, at 19:18, Paul Norman  wrote:
>> 
>> Both of these seem to be software rather than file format definitions. I had 
>> a quick look around the repo, but I couldn't find a format definition except 
>> that for standard OSM PBF.
> 
> Hi Paul,
> 
> They are indeed software, both of which store planet-scale OSM data sets and 
> perform on-demand geographic extracts, and the second one applies minutely 
> updates. I may have misunderstood something, but I was under the impression 
> that the original poster was looking for a way to fetch up to date, 
> geographically contiguous chunks of PBF data for use in generating image 
> tiles.
> 
> 
> So these two links are not file format definitions, they are essentially 
> special purpose database systems, but of course each one has its own internal 
> on-disk representation of bulk OSM data, which is distinct from PBF. I would 
> not consider PBF to be an optimal bulk storage format if you intend to 
> perform a continuous stream of minutely updates (delete, move, change tags) 
> on arbitrary OSM entities scattered around the world. Performing random 
> access updates inside PBF files could get awkward. Say for example you need 
> to update a tag on way 142563. Where is that way located geographically, in 
> which file, and what is its position inside that file? Once you locate that 
> file, you’d need to decompress the entire file and scan through it to find 
> the way, and if the edit makes the file block larger than it was before, 
> you’d need to shift and rewrite the rest of the file. 
> 
> So I was providing these repos as examples of systems that were intended from 
> the beginning to allow minutely updates and arbitrary PBF extracts. They 
> might need to be completed or adapted, but could provide a starting point.
> 
> The second (Java) version that I cited is however part of an OSM handling 
> library, which does specify its own file format called VEX. Like PBF, that is 
> a data exchange format for passing around OSM regions in files. But neither 
> PBF nor VEX format is used to store the bulk, spatially indexed data 
> internally.
> 
> Andrew
> ___
> 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] Migrating osm.org to vectors/Kartotherian

[Stadin, Benjamin]

I know I¹m a bit late...

Am 01.11.15, 04:04 schrieb "Paul Norman" unter :

>>#2 SQL -> Vectors
>>This is very similar to the set of SQL statements that osm-carto uses
>>to generate data. Mapbox is now on version 6 of vtile structure, so it
>>is obviously a hard problem to nail down. [4] We could make it
>>compatible, or come up with a different structure.
>>TBD: vtile structure
>
>A style designed for showing off OSM data and mapper feedback will put
>different data into vector tile different ways than one designed for
>Wikimedia's purposes. If osm-carto was vector tile based, we'd probably
>be changing the vector tile definitions every 6-12 weeks, and these
>would be backwards-incompatible changes.

Maybe one option would be to "borrow" some parts of the GeoPackage spec
[1] to handle the data aspect.
There is no single answer for how to add tile data to GPKG, but how about
starting with defining a default "OSM presentation data export":
- A standard GPKG container
- including a (probably large) set of gpkg_data_columns definitions
- pure vector features (no tile data at this point)
- versioning (could be done in a quite simple way then probably, since
several concerns are defined by GPKG itself)

Other "consumers" could then add own data and definitions to this
container in a standardized way
(e.g. append some data field and expect the existence of a certain
gpkg_data_columns definition).

There could be a several such OSM containers (though I think the feedback
data could be made part of the presentation data container).

In a next step, this data container can then be further optimized for
rendering by creating tile sets or else - while retaining all data as
defined within the GPKG.
Maybe there can be a tile data BLOB and a user data BLOB (both protocol
buffers) as part of the tile data table.
The user data proto buf must then by definition be an exact match to the
gpkg_data_columns.
So this custom data could be a simple addition to the GPKG tile data spec,
and it should work for both raster and vector tile data.
I've recently made a similar suggestion to a related topic for MapBox on
Github [2]. John Firebaugh's suggestion for vector tiling was to create a
WebP like extension for MapBox vector tiles within GPKG for their next
offline db.

In the end there could (ideally) be a concise set of standardized OSM
exports for different purposes,
a standardized way to deal with and extend this data by external tools and
data, and some way to deal
with different render data formats (e.g. vector tiles or else) with
embedded data. The latter can¹t be standardized easily in my opinion, we
have for example pretty different demands about the rendering data for our
native GL map renderer.

[1] http://www.geopackage.org/spec/
[2] 
https://github.com/mapbox/mapbox-gl-native/issues/3373#issuecomment-1671620
61


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

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Stadin, Benjamin]

Hi Peter,

Most what you said is already solved by data driven style possibilities
and clustering that you have already with some existing WebGL libraries.
E.g. which city label takes priority when zooming out over another city¹s
label (by default the one with highest population), or whether city labels
take priority over icons.

I do not see why there would be any difference doing this on client or
server side, besides you¹d have to adapt a few things at first of course.
For an example, if you have an algorithm that places your labels depending
on language and geometrical shape of labels, then this algorithm can
likely be applied in realtime on the client side.
If you have different anchor points for labels depending on language, then
this is even less a problem: Decide by a filter rule in realtime which
labels to render, each label may have a different position. This can be as
simple as a single line in your style rule.

Regards
Ben


Am 31.10.15 09:32 schrieb "Peter Wendorff" unter
:

>Hi Colin,
>
>just stitching a labels-layer and a base layer together would work, but
>most often would not look well.
>
>Map rendering involves deciding which labels to show considering more
>than just the labels, but icons and shields etc. as well to avoid
>overlapping between all of them.
>
>You don't want to get a map where the label overlaps icons.
>
>As names in different languages differ in their need for geometrical
>space on the map, these placement decisions have to be taken for each
>language differently, thus the labels layer would include icons and
>stuff like that as well - even oneway and so on.
>
>Of course it would be possible to do, but the result would look worse
>than our current maps.
>
>regards
>Peter
>
>Am 30.10.2015 um 12:41 schrieb Colin Smale:
>> Can't we have a multi-lingual map by overlaying a base tile with a
>> transparent text layer in the chosen language? We wouldn't *need* vector
>> tiles for that, just a bit more storage (bitmap-based text layers should
>> compress nicely) and clients which can handle the selection and display
>> of the extra layer, which is pretty commonplace these days anyway).
>>
>> --colin
>>
>> On 2015-10-30 12:29, Oleksiy Muzalyev wrote:
>>
>>> I've heard from the OSM operations team's member at the conference
>>> that it is the question of the servers' infrastructure cost.
>>>
>>> But if we have a vector-based map itself language selection, that we
>>> could just add tags /name:fr/ or /name: ru/ and have the OSM map of
>>> say New York in French or in Russian for tourists. Or map of Siberia
>>> in German also for tourists, Middle East in English, etc. without any
>>> additions cost on the server side. It is not that difficult to add
>>> such multi-language tags. There could be also the map in Basque,
>>> Catalan, Kurdish, Scots and other smaller (by number of speakers)
>>> languages without any additional cost and without a civil conflict.
>>>
>>> I realize that mobile hardware is not enough advanced for that yet and
>>> vector-based technology is only in an development stage.
>>>
>>> brgds
>>> Oleksiy
>>>
>>> On 30.10.2015 12:06, Maarten Deen wrote:
 On 2015-10-30 11:53, Oleksiy Muzalyev wrote:
> One of the advantages of the the vector-based map would be the
> multilingualism.
>
> For instance at the moment the OSM map of the Middle East is
>basically
> useless for me as I do not know the Arabic alphabet yet. But as far
>as
> I understand and as I heard at the conference the vector-based map
> would allow the choice of a language of the map itself.

 I do not see how that can not be solved with png-based tiles. You
 only have to render the tiles.
 The method for detecting which tileset/language to show is the same.

 BTW: it is still not as simple as rendering "in a different
 language". Then you start rendering a map in English and see names
 like "Cologne" or "Brussels"  show up on the map.

 Regards,
 Maarten

 ___
 dev mailing list
 dev@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/dev
>>>
>>>
>>> ___
>>> dev mailing list
>>> dev@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/dev
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
>
>
>___
>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] Migrating osm.org to vectors/Kartotherian

[Stadin, Benjamin]

One such service would be MapBox [1] itself. And in my opinion
mapbox-gl-js would be a natural choice for the client part. MapBox is
doing a really good job, and this is getting really solid.

I wrote a tiny script to create a mapbox-gl-js package for own deployment
[2]. It doesn't do much useful at the moment, other than doing a basic
host config of the build and generating and packaging some of the required
assets. No custom style integration, and no font generation (I wanted to
add this to the script, so they'd be generated from freetype fonts [3]
using fontnik [4]).

~Ben

[1] https://www.mapbox.com/mapbox-gl-js/examples/
[2] https://github.com/benstadin/mapbox-gl-js-packager
[3] https://fedorahosted.org/liberation-fonts/
[4] https://github.com/mapbox/node-fontnik



Am 30.10.15 12:50 schrieb "Daniel Koć" unter :

>W dniu 30.10.2015 11:10, Martin Koppenhoefer napisał(a):
>
>> - vector maps are consuming more energy to display (because have to be
>> calculated/rendered) -> problem on mobile devices, but also generally
>
>Mobile applications like OsmAnd show that while it really is slower,
>it's still usable.
>
>I would not like to "migrate" osm.org to anything - including vector
>tiles - right now. I would rather like to have vector playground to test
>it and draw some conclusions myself. Yet at this moment I'm not aware of
>such experimental service.
>
>-- 
>"The train is always on time / The trick is to be ready to put your bags
>down" [A. Cohen]
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev


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

[OSM-dev] Tile server and Nominatim setup @ Openstreetmap.org

[Stadin, Benjamin]

Hi list,

I've installed the rails port and imported a small map via osmosis. Next thing 
is to install a tile server, and change the default settings of the rails port 
to use it.

I'm interested in production configurations. There are several tutorials for 
installing Mapnik, but so far I found none that covers in detail the 
dependencies and configuration for installing a complete and scalable 
Openstreetmap stack on your own (rails port + tile service + minutely updates + 
Nominatim).

Do you have some details how to accomplish installing the complete stack, close 
to how it works at openstreetmap.org?

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

[OSM-dev] Extracting map regions

[Stadin, Benjamin]

Hi,

I want to import planet.osm into a Postgresql db (I'm considering to use imposm 
for the import). Once I have the whole planet imported, I need to extract many 
small regions (say max 5km * 5km max). The area is user-definable in my case, 
it can be any boundary with mentioned maximum size.

I'm interested in how regional / metro extracts are done for the cities 
provided at the OSM download page, what options there are (especially 
performance-wise) and what I need to take care of otherwise when extracting 
regions (missing relationships when clipping, routing network issues, or else).

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