[OSM-dev] OSGeo-Live team needs help: Someone who looks after OSM data, tools and writes documentation is needed

[Sebastiaan Couwenberg]

 Forwarded Message 
Subject: [Live-demo] OSGeo-Live team needs help: Someone who looks after
OSM data, tools and writes documentation is needed
Date: Sat, 11 Jun 2016 13:06:11 +0200
From: Astrid Emde 
To: Live Demo 

Hello OSM enthusiasts,

this is a mail from the OSGeo-Live team [1]. OSGeo-Live is a linux based
distribution of open source geospatial software which is handed out at
conferences around the world, and used as the foundation for open source
geospatial training courses.

We use OSGeo-Live to teach enthusiasts how to create geospatial data
with free tools.

At the moment, we include an extract of OSM data, and how to use Mapnik,
but we'd love to be doing a better job of promoting OSM which in turn
should attract motivated geospatial people into the OSM community.

The catch is that we need some help understanding OSM tools, and keeping
these tools and docs up to date, which is where you (the OSM community)
comes in.

We are hoping to find one or two people who can help us write
Application Overview [2] and 10-15 min Quickstart docs, and act as a
point of contact to advise on OSM as we build each release.

This is what we are looking for. Are you interested to help? It could be
a single person or a team. And the OSGeo-Live team is also supporting,
when help is needed.

This is what you have to do - don't worry, it should not be too much work ;)
* provide the up-to-date software every half a year when a new version
of OSGeo-Live is coming out
* check the documentation (Overview and Quickstart)  -> is there
anything to update
* provide new up-to-date OSM data (f.e. for version 10.0 we will provide
data from Bonn where FOSS4G 2016 will be in august)
* provide a quickstart (tutorial to help people to get to know OSM and
make the first steps) - this quickstart does not exist at the moment and
has to be written
* OSM covers data and OSM tools (like JOSM) which are not documented yet
** we only have a documentation for Mapnik
http://live.osgeo.org/en/overview/mapnik_overview.html

Are you interested? If yes - please let us know. (subscribe to the
OSGeo-Live (Live-demo) mailing list [4] or write to astrid_e...@osgeo.org)

Regards

Astrid from OSGeo-Live PSC

[1] http://live.osgeo.org
[2] OSM Overview http://live.osgeo.org/en/overview/osm_dataset_overview.html
[3] OSGeo-Live Dokumentation in the OSGeo wiki
http://wiki.osgeo.org/wiki/Live_GIS_Disc
[4] Live-demo mailing list
https://lists.osgeo.org/mailman/listinfo/live-demo

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

Re: [OSM-dev] Mukti and Gargi fonts for openstreetmap-carto

[Sven Geggus]

Paul Norman  wrote:

> Something I've found when researching fonts for Asian languages is that 
> the versioning, releases, name consistency, and other releasing 
> engineering matters are often inadequate. Coupled to this, many webpages 
> for fonts disappear after a few years.

Hm so can't we just go for "No Tofu" fonts?

They are supported by Google and are available as a Debian Package:
https://www.google.com/get/noto/
https://packages.debian.org/sid/fonts-noto

However I have no Idea if all of the south asian scripts are covered.

Regards

Sven

-- 
Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[OSM-dev] OSM WATER POLYGONS – again

[SandorS]

To my great satisfaction and surprise, in the mail from about the start of 
March we could read in the
“dev Digest, Vol 131, Issue 25,” the issue “2. Upcoming change in files on 
openstreetmapdata.com”.
The changes relate to the creation of regular tiles for land and water 
coastline based large areas instead of splitting up these areas onto irregular 
rectangular partly overlapping areas. This issue has been discussed (on this 
forum) in years and I think this is now the right direction
Arguments for changes, as well as examples, we could find in the documentation 
accessible via 
http://blog.imagico.de/on-slicing-the-world-news-from-openstreetmapdata-com/ 
link.
As stated there, many application developers use these “water/land polygons” 
and the interest for them and for the tools used is constantly growing. With 
large respect for that and for the effort invested by the authors, I would just 
like to add some (constructive) notes that could maybe help faster and more 
robust accomplishment of the changes.
1. The (coastline) data/input validator you use still has certain holes:
- There are areas in/over areas. These are probably missing islands in lakes or 
rivers.
- There are still many replicated consecutive points/nodes on borders.
- There are many open land border polygons (especially those crossing the World 
border) in the   coastline.
- There are also certain misalignments between the land border polygons and the 
World border rectangle (especially the east/south/west border segments of the 
Antarctica). Just to mention some.
2. The planet_sea and its (regular) tiled representation:
- There is a doubt in the documentation about the creation of the planet_sea. 
This doubt is unnecessary as my experience shows. For instance, in the Mercator 
projection, we can generate a perfect planet_sea by inversion of the 
planet_land and we can do it in some seconds (on my laptop).
- The z9 “simplified” and “slicing” water polygons creation seams OK. However, 
from the methodology point of view the planet_land 
scaling-simplifying-inverting is never the same as scaling-simplifying the 
planet_sea. Especially, the differences are obvious on the World border. Note 
that the World border/frame issue is complex and almost all mapping systems 
have problems with it.
- The tile overlaps should be obsolete. Correct rendering and tile/frame 
matching is a basic application responsibility.
- Using higher scale levels (z9) for rendering lower scale presentations (like 
z2, z3…) has many aesthetic, topological and performance related issues.
- The tiling of water areas is probably obsolete. I would suggest considering 
of on-the-fly tiling.
3. The “generalized” zoom z8-z1 map versions. 
- All small area borders (islands) appear as oval and consequently larger.
 - There are many unexpected breaks and connections on area objects and 
consequently many lakes appear on fiords, islands on peninsulas and so on.
- The production of the zi data is rather complex and time-consuming. 
- The re-vectorised (z8-z1) versions of the polynomial approximations contain 
4-5 times more vectors than the corresponding versions created by a robust 
cartographic generalization.
Finally, if interested, you may find many arguments, details and examples in 
the white paper here:
https://drive.google.com/file/d/0B6qGm3k2qWHqd1UtcXNVWUVtN3M/view?usp=sharing
Regards, Sandor.


Sent from Mail for Windows 10

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

[OSM-dev] Libosmium release 2.7.2

[Jochen Topf]

Hi!

Just notices I hadn't written anything about the new libosmium release I did
this week. 2.7.2 fixes two important problems, one is a data corruption issue
in the sparse_mmap_array index which appeared in the 2.7 release, the other
concerns input and output of OSM data in text form which depended on the locale
setting. Map coordinates were parsed and written in the current locale instead
of always using the decimal dot (.).

What might be more important for lots of users is that the new I/O code makes
writing of XML, OPL, and debug formats much faster. Converting a planet from
PBF to XML or OPL is done twice as fast now. (15 minutes instead of 30 minutes
on the machine I tested this on.)

https://github.com/osmcode/libosmium/releases/tag/v2.7.2

Debian Packages are already available in Unstable and will be available
for Testing and Jessie backports in due course.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-351-31778688

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

[OSM-dev] New release of osmium tool v1.3.1

[Jochen Topf]

Hi!

I recently released version 1.3.1 of the Osmium Tool, a fast command line tool
for handling OSM data built upon the libosmium library. This release includes a
new "show" subcommand for a quick peek into any OSM file. The "getid"
subcommand can now recursively add references objects and the "renumber"
command is now much faster and more memory efficient. Full release info is at
https://github.com/osmcode/osmium-tool/releases/tag/v1.3.1 .

You can get it from https://github.com/osmcode/osmium-tool . Debian packes
are available in Unstable, packages for Testing and Jessie Backports will
appear in due course.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-351-31778688

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/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

[OSM-dev] Overpass-API 0.7.52 : HTTP 429 error even after kill_my_queries

[François Lacombe]

Hi all,

It seems that GET kill_my_queries request won't prevent oAPI to give HTTP
429 error.

I'm curently using a script which send synchronously 10 queries to oAPI on
http://overpass-api.de/api (v0.7.52).
It calls kill_my_queries between each (even if it sounds useless, just to
really be sure no other request is still pending from my IP).

And this is what I get in the log :

[00:42:07] Kill Overpass-API OK : No query running from IP 1.2.3.4
[00:42:08] oAPI request : [timeout:480];
area["ISO3166-1"="FX"]["admin_level"="3"]->.france;  (node (area.france)
["power"="substation"] ["operator"="RTE"]  ["substation"="transmission"]
["ref:FR:RTE_nom"](newer:"2016-06-10T23:00:00+0200"); way  (area.france)
["power"="substation"]  ["operator"="RTE"]  ["substation"="transmission"]
["ref:FR:RTE_nom"](newer:"2016-06-10T23:00:00+0200")); out body;>; out skel;
[00:42:23] HTTP 429 runtime error: open64: 0 Success
/osm3s_v0.7.52_osm_base
Dispatcher_Client::request_read_and_idx::rate_limited. Another request from
your IP is still running.

[00:42:24] Kill Overpass-API OK : No query running from IP 1.2.3.4
[00:42:25] oAPI request : [timeout:480];
area["ISO3166-1"="FX"]["admin_level"="3"]->.france;  (node (area.france)
["power"="substation"]["substation"="distribution"]["ref:FR:RTE_nom"]
(newer:"2016-06-10T23:00:00+0200"); way (area.france)
["power"="substation"] ["substation"="distribution"]["ref:FR:RTE_nom"]
(newer:"2016-06-10T23:00:00+0200")); out body;>; out skel;
[00:42:40] HTTP 429 runtime error: open64: 0 Success
/osm3s_v0.7.52_osm_base
Dispatcher_Client::request_read_and_idx::rate_limited. Another request from
your IP is still running.

and so on...

Can someone explain why kill_my_queries tells there is no request and then
an interpreter call fails in HTTP 429 ?

Kind regards

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Mukti and Gargi fonts for openstreetmap-carto

[Paul Norman]

On 6/11/2016 11:44 AM, Sven Geggus wrote:

Hm so can't we just go for "No Tofu" fonts?

They are supported by Google and are available as a Debian Package:
https://www.google.com/get/noto/
https://packages.debian.org/sid/fonts-noto


Well, no one has done much research into issue #1067 which covers this. 
Comments are welcome there.


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

Re: [OSM-dev] Overpass-API 0.7.52 : HTTP 429 error even after kill_my_queries

[Michael Larsen]

Hi,

A while back I tried consuming augmented diffs from overpass API 
(sequentially, once per minute), with similar results.  My conclusion back 
then was that the rate limiting algorithm had other ways of attributing your 
load on overpass than merely the number of simultaneous connections. My guess 
is that your queries are simply 'too big' and placed 'too closely' in time to 
be allowed by the rate limiting algorithm. If you add some delay between your 
queries I guess they will be fine.

Back when trying to consume minutely augmented diffs I ended up concluding 
that this was not possible on a minutely basis due to the rate limiting 
algorithm, unfortunately.

Regards,
MichaelVL

On søndag den 12. juni 2016 00.53.08 CEST François Lacombe wrote:
> Hi all,
> 
> It seems that GET kill_my_queries request won't prevent oAPI to give HTTP
> 429 error.
> 
> I'm curently using a script which send synchronously 10 queries to oAPI on
> http://overpass-api.de/api (v0.7.52).
> It calls kill_my_queries between each (even if it sounds useless, just to
> really be sure no other request is still pending from my IP).
> 
> And this is what I get in the log :
> 
> [00:42:07] Kill Overpass-API OK : No query running from IP 1.2.3.4
> [00:42:08] oAPI request : [timeout:480];
> area["ISO3166-1"="FX"]["admin_level"="3"]->.france;  (node (area.france)
> ["power"="substation"] ["operator"="RTE"]  ["substation"="transmission"]
> ["ref:FR:RTE_nom"](newer:"2016-06-10T23:00:00+0200"); way  (area.france)
> ["power"="substation"]  ["operator"="RTE"]  ["substation"="transmission"]
> ["ref:FR:RTE_nom"](newer:"2016-06-10T23:00:00+0200")); out body;>; out skel;
> [00:42:23] HTTP 429 runtime error: open64: 0 Success
> /osm3s_v0.7.52_osm_base
> Dispatcher_Client::request_read_and_idx::rate_limited. Another request from
> your IP is still running.
> 
> [00:42:24] Kill Overpass-API OK : No query running from IP 1.2.3.4
> [00:42:25] oAPI request : [timeout:480];
> area["ISO3166-1"="FX"]["admin_level"="3"]->.france;  (node (area.france)
> ["power"="substation"]["substation"="distribution"]["ref:FR:RTE_nom"]
> (newer:"2016-06-10T23:00:00+0200"); way (area.france)
> ["power"="substation"] ["substation"="distribution"]["ref:FR:RTE_nom"]
> (newer:"2016-06-10T23:00:00+0200")); out body;>; out skel;
> [00:42:40] HTTP 429 runtime error: open64: 0 Success
> /osm3s_v0.7.52_osm_base
> Dispatcher_Client::request_read_and_idx::rate_limited. Another request from
> your IP is still running.
> 
> and so on...
> 
> Can someone explain why kill_my_queries tells there is no request and then
> an interpreter call fails in HTTP 429 ?
> 
> Kind regards
> 
> François
> 
> --
> *François Lacombe*
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 



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