Integers are 32 bits only #895

Closed
artemp opened this Issue Oct 11, 2011 · 8 comments

Comments

Projects
None yet
3 participants
Owner

artemp commented Oct 11, 2011

When retrieving integers from a datasource and comparing them, they're truncated/overflowed to 32 bits.

Owner

artemp commented Oct 19, 2011

Currently all integer values are expected to be 32-bit signed integers. We should add support for long_long on platforms where 64-bit integers are natively supported. Using floating point numbers in both expression and feature values can be used as a temp workaround:

>>> import mapnil2
>>> expr=mapnik2.Expression("[VAL] > 3e9 and [VAL] < 1.2e10")
>>> f['VAL']=3.1e9
>>> expr.evaluate(f)
True  
Owner

springmeyer commented Jul 3, 2012

Just discussed this with @artemp - actionable thing here is to look into tradeoffs of various approaches. Which has the least overhead and also would make the most sense going into the future.

  1. should we handle both 32bit and 64 bit ints in mapnik::value_base? (https://github.com/mapnik/mapnik/blob/master/include/mapnik/value.hpp#L89)

  2. should we detect arch and use the appropriate max integer type for the platform?

  3. should we just go 64 all the way (or use boost cstint to handle) and not worry about 32 bit platforms?

Just needs some time and research.

@springmeyer springmeyer referenced this issue in tilemill-project/tilemill Sep 27, 2012

Closed

Failed to parse expression: Carto CSS #1726

I have a problem dealing with bigint datatype in mapnik: Within the postgis plugin I get the osm_id column from the postgresql database. This column has datatype bigint. It is processed in postgis_featureset.cpp like this:

                case 20: //int8/BigInt
                {
                    // TODO - need to support boost::uint64_t in mapnik::value
                    // https://github.com/mapnik/mapnik/issues/895
                    int val = int8net(buf);
                    feature->put(name, val);
                    break;
                }

Is this issue already solved, or migth the osm_id from database be truncated/overflowing?

I am further taking the osm_id from the feature like this:
mapnik::feature_impl::value_type osm_id = feature.get(std::string("osm_id"));

How can I cast/convert the value_type back to bigint again? Is there a builtin datatype in mapnik to use for bigint?

Thx for help!
Regards,
Michbeck

Owner

artemp commented Nov 30, 2012

@michimichbeck - Thanks for reminding that we need to add support for 64-bit integers! I'm working on it now and I'll post once I have working impl.

Owner

artemp commented Nov 30, 2012

Hi Michbeck,

Thanks for reminding that we need to add support for 64-bit integers! I'm
working on it now and I'll post once I have working impl.

Cheers
Artem

On 30 November 2012 09:26, Michael Keutel notifications@github.com wrote:

I have a problem dealing with bigint datatype in mapnik: Within the
postgis plugin I get the osm_id column from the postgresql database. This
column has datatype bigint. It is processed in postgis_featureset.cpp like
this:

            case 20: //int8/BigInt
            {
                // TODO - need to support boost::uint64_t in mapnik::value
                // https://github.com/mapnik/mapnik/issues/895
                int val = int8net(buf);
                feature->put(name, val);
                break;
            }

Is this issue already solved, or migth the osm_id from database be
truncated/overflowing?

I am further taking the osm_id from the feature like this:
mapnik::feature_impl::value_type osm_id =
feature.get(std::string("osm_id"));

How can I cast/convert the value_type back to bigint again? Is there a
builtin datatype in mapnik to use for bigint?

Thx for help!
Regards,
Michbeck


Reply to this email directly or view it on GitHubhttps://github.com/mapnik/mapnik/issues/895#issuecomment-10883238.

Owner

springmeyer commented Dec 18, 2012

see also mapbox/tilemill#1846

Owner

springmeyer commented Dec 19, 2012

closed by #1661, @michimichbeck - fyi, if you are running Mapnik master the feature_id's are still not 64 bit, but will be soon, see: #1662

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment